> Sürekli Süreç İyileştirme > Olay Yönetimi > Zendesk Support > Veri Şablonu

Olay Yönetimi `Veri Template`'iniz

Zendesk Support

Olay Yönetimi Nitelikleri (24) Olay Yönetimi Faaliyetleri (13) Veri Çekim Kılavuzları (4)

Olay Yönetimi `Veri Template`'iniz

Bu şablon, olay yönetimi sürecinizi etkili bir şekilde analiz etmek için gereken temel verilere ilişkin yapılandırılmış bir genel bakış sunar. Toplanması gereken temel öznitelikleri, izlenecek kritik aktiviteleri özetler ve bu verileri Zendesk Support'tan çıkarmak için pratik rehberlik içerir. Process Mining projenizin sağlam ve eksiksiz bir veri setiyle başlamasını sağlamak için kullanın.

Toplanması Önerilen Nitelikler
Süreç haritalaması için izlenecek temel faaliyetler
Pratik veri çıkarma rehberliği

Event log'lara yeni mi başlıyorsunuz? Öğrenin Process Mining event log'u nasıl oluşturulur.

Şablonu İndir

Olay Yönetimi Nitelikleri

Bunlar, olay yönetimi sürecinizin kapsamlı bir analizi için event log'unuza dahil etmeniz önerilen veri alanlarıdır.

5 Gerekli 7 Önerilen 12 İsteğe Bağlı

	Ad	Açıklama
	Olay Kimliği TicketId	Her olay talebi için benzersiz sistem tarafından oluşturulan tanımlayıcı.
Açıklama Olay Kimliği (Incident ID), Zendesk Support içindeki her olay vakasını benzersiz bir şekilde tanımlayan birincil anahtardır. Process Mining için CaseId olarak hizmet eder ve olayın oluşturulduğu andan kapanana kadar tüm ilgili aktiviteleri, durum değişikliklerini ve iletişimleri birbirine bağlar. Analizde bu kimlik, her olayın uçtan uca yolculuğunu yeniden yapılandırmak için çok önemlidir. Toplam çözüm süresi, aktarım sayısı ve bireysel vakalar için hizmet seviyesi anlaşmalarına uyum gibi metrikleri izlemek amacıyla olay verilerinin toplanmasını sağlar. 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 Bu, tüm olayları tek bir olaya bağlayan, tüm yaşam döngüsünü izlemeyi ve süreç performansını doğru bir şekilde analiz etmeyi mümkün kılan temel tanımlayıcıdır. Nereden alınır Zendesk Talepler API'si (/api/v2/tickets/{id}), id alanı. Örnekler 19428230113521941055
	Olay Zaman Damgası EventTimestamp	Aktivitenin gerçekleştiği kesin tarih ve saat.
Açıklama Bu zaman damgası, olay yaşam döngüsünde bir olayın (yorum eklendiği veya durumun değiştirildiği gibi) tam olarak ne zaman gerçekleştiğini kaydeder. Bir vaka içindeki tüm aktiviteler için kronolojik sırayı sağlar. Bu öznitelik, zamana dayalı her türlü Process Mining analizi için temeldir. Aktiviteler arasındaki döngü sürelerini hesaplamak, bekleme sürelerini belirlemek, genel vaka süresini ölçmek ve farklı zaman dilimlerindeki süreç performansını analiz etmek için kullanılır. Doğru zaman damgaları, olayları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 Dashboard'ları oluşturmak için esastır. Neden önemli Zaman damgaları, tüm aktiviteler için kronolojik bağlam sağlayarak sürelerin hesaplanmasını, darboğazların belirlenmesini ve süreç performansının zaman içindeki analizini mümkün kılar. Nereden alınır Zendesk Talep Denetimleri API'si (/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
	Aktivite ActivityName	Olay yaşam döngüsünde belirli bir noktada meydana gelen iş aktivitesinin veya olayın adı.
Açıklama Bu öznitelik, 'Olay Oluşturuldu', 'Talep Temsilciye Atandı' veya 'Olay Çözüldü' gibi olay yönetimi sürecinde atılan belirli bir adımı veya eylemi tanımlar. Bu aktiviteler, sistem değişikliklerinin kaydedildiği Zendesk'ten alınan event log veya denetim izleme verilerinden türetilir. Process Mining'de, bu aktivitelerin sırası tüm analizin temelini oluşturan süreç haritasını oluşturur. Aktivite akışını analiz ederek, kuruluşlar olayların gerçekte hangi yolları izlediğini keşfedebilir, adımlar arasındaki darboğazları belirleyebilir, yeniden işleme döngülerini (örneğin, çözülmüş bir talebi yeniden açma) ölçebilir ve tanımlanmış standart bir sürece uygunluğu kontrol edebilir. Neden önemli Aktivite sırası, verimsizlikleri, sapmaları ve iyileştirme fırsatlarını belirlemek için Process Mining analizinin temelini oluşturan süreç akışını tanımlar. Nereden alınır Zendesk Bilet Denetimleri API'sindeki olaylardan türetilir. Örneğin, durum alanındaki bir Değişiklik olayı 'Durum Değişti' olarak eşlenebilir. Örnekler Olay OluşturulduBilet Temsilciye AtandıDurum Beklemede Olarak DeğiştirildiOlay ÇözüldüOlay Kapatıldı
	Kaynak Sistem SourceSystem	`Olay verisinin` çıkarıldığı `sistem`.
Açıklama Bu öznitelik, süreç verilerinin kaynağını tanımlar. Bu görünüm için değer statik olacaktır; örneğin, tüm olayların ve özniteliklerin o sistemden alındığını belirten 'Zendesk Support'. Birden fazla sistemden gelen verilerin birleştirildiği ortamlarda, bu alan farklı veri kaynaklarını ayırt etmek için kritiktir. Veri bütünlüğünü sağlamaya yardımcı olur ve Zendesk'teki olay yönetimi sürecini başka bir ITSM aracıyla karşılaştırmak gibi kaynağa özel analizlere olanak tanır. Neden önemli Verinin kökenini tanımlar, bu da veri yönetimi ve birden fazla kaynak sistemden gelen verileri birleştiren analizler için kritik öneme sahiptir. Nereden alınır Veri dönüşümü sırasında veri kaynağını belirlemek için ayarlanan statik değer. Örnekler Zendesk SupportZendesk
	Son Veri Güncellemesi LastDataUpdate	Bu süreç için verilerin en son ne zaman yenilendiğini gösteren zaman damgası.
Açıklama Bu öznitelik, kaynak sistemden en son veri çekiminin veya güncellemesinin tarih ve saatini kaydeder. Genellikle belirli bir yenileme döngüsünden gelen tüm veri setine uygulanan tek bir değerdir. Bu bilgi, veri yönetimi ve Process Mining analizi kullanıcıları için hayati önem taşır. Verilerin güncelliği hakkında bağlam sağlayarak, analistlerin mevcut en güncel bilgileri görüp görmediklerini anlamalarına yardımcı olur. Bu, operasyonel performansı izlemek ve analize dayalı zamanında kararlar almak için özellikle önemlidir. Neden önemli Veri güncelliği hakkında kritik bağlam sağlayarak, kullanıcıların analizin ne kadar güncel olduğunu ve verilerin en son ne zaman alındığını anlamalarını sağlar. Nereden alınır Veri yenileme 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	Olay için şu anda atanmış destek ekibi veya grubu.
Açıklama Bu öznitelik, olaydan hangi ekibin sorumlu olduğunu gösterir. Olaylar genellikle farklı destek katmanları veya özel gruplar arasında hareket eder; örneğin 'L1 Destek'ten 'Ağ Ekibi'ne. Bu, süreç aktarımlarını analiz etmek ve darboğazları belirlemek için kritik bir boyuttur. Olayların gruplar arasında nasıl aktığını izleyerek, analistler ekipler arası bağımlılıkları ölçebilir, belirli ekipler için kuyruk sürelerini hesaplayabilir ve yönlendirme kurallarını optimize edebilir. Doğrudan 'Aktarım ve Yeniden İşleme Analizi' Dashboard'unu destekler. Neden önemli Ekipler arası aktarımları analiz etmek, ekibe özel darboğazları belirlemek ve kuyruk sürelerini ölçmek için gerekli olan ekip sahipliğini izler. Nereden alınır Zendesk Talepler API'si, group_id alanı. Değişiklikler Talep Denetimleri API'sinde loglanır. Örnekler L1 DestekL2 Ağ EkibiL3 AltyapıFaturalandırma
	Atanan Temsilci Assignee	Olayı şu anda ele almak üzere atanmış bireysel destek temsilcisi.
Açıklama Bu öznitelik, belirli bir zamanda olaydan sorumlu belirli temsilciyi tanımlar. Atanan kişideki değişiklikler, işin bir kişiden diğerine devredildiğini gösteren kritik olaylardır. Atanan temsilciyi analiz etmek, iş yükü dağılımını, bireysel performansı ve işbirliği kalıplarını anlamaya yardımcı olur. Bu alandaki değişiklikleri izlemek, 'Olay Başına Ortalama Aktarım' KPI'ını hesaplamak ve olayların sıklıkla elden ele dolaştığı durumları (bilgi eksiklikleri veya verimsiz yönlendirmeyi gösterebilir) belirlemek için esastır. Neden önemli Sorumlu temsilciyi tanımlar, iş yükü analizini ve süreç verimsizliklerini belirlemek için kritik olan devirlerin izlenmesini sağlar. Nereden alınır Zendesk Talepler API'si, assignee_id alanı. Değişiklikler Talep Denetimleri API'sinde loglanır. Örnekler Can DemirAyşe YılmazServis Masası Otomasyonu
	Olay Bitiş Zamanı EventEndTime	Bir aktivitenin tamamlandığını gösteren timestamp.
Açıklama Olay Bitiş Zamanı (Event End Time), bir aktivitenin sonunu işaret eder. Event Log verilerinde, bir aktivitenin bitiş zamanı genellikle o olaya ait bir sonraki aktivitenin başlangıç zamanı olarak kabul edilir. Bir olayın en son aktivitesi için bitiş zamanı, başlangıç zamanıyla aynı olabilir. Bu öznitelik, bireysel aktivitelerin süresini (ProcessingTime) ve aktiviteler arasındaki bekleme süresini hesaplamak için esastır. Bu bilgi, darboğaz analizinin temelini oluşturur ve analistlerin yalnızca bir adımın ne kadar sürdüğünü değil, aynı zamanda o adım başlamadan önce olayın ne kadar süreyle boşta kaldığını da görmelerini sağlar. Neden önemli Detaylı darboğaz analizi yapmak ve süreç gecikmelerini belirlemek için temel olan aktivite sürelerinin ve bekleme sürelerinin hesaplanmasını sağlar. Nereden alınır Aynı vaka içindeki sonraki olayın başlangıç zamanı olarak hesaplanır. Son olayın bitiş zamanı, başlangıç zamanıyla veya vaka kapanış zamanıyla aynı olabilir. Örnekler 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Öncelik TicketPriority	Olaya atanan öncelik seviyesi; örneğin 'Düşük', 'Normal', 'Yüksek' veya 'Acil'.
Açıklama Bir olayın önceliği, bir yanıt ve çözüm için gereken aciliyeti belirler. Destek ekibi içinde iş önceliklendirmesi ve kaynak tahsisinde önemli bir faktördür. Süreç analizinde öncelik, olayları süreç akışlarını ve performanslarını karşılaştırmak için segmentlere ayırmak için kullanılır. Örneğin, analistler 'Acil' olayların gerçekten 'Düşük' öncelikli olanlardan daha hızlı çözülüp çözülmediğini kontrol edebilirler. SLA'lar genellikle öncelik seviyelerine göre tanımlandığından, SLA uyumluluğunu izlemek için de kullanılır. 'Öncelik Değişim Oranı' KPI'ı, bu alandaki değişiklikleri izlemeye dayanır. Neden önemli Bu öznitelik, analizi segmentlere ayırmak, önceliklendirme etkinliğini değerlendirmek ve farklı aciliyet seviyeleri için SLA uyumluluğunu izlemek için çok önemlidir. Nereden alınır Zendesk Talepler API'si, priority alanı. Değişiklikler Talep Denetimleri API'sinde loglanır. Örnekler düşüknormalyüksekurgent
	Raporlama Kanalı Channel	Olayın başlangıçta bildirildiği kanal; örneğin 'Email', 'Web' veya 'API'.
Açıklama Bu öznitelik, son kullanıcı veya sistem tarafından olay talebini oluşturmak için kullanılan yöntemi yakalar. Kanalı anlamak, olay kaynaklarını analiz etmek ve destek sürecini buna göre uyarlamak için önemlidir. Olayları kanala göre analiz etmek farklı kalıpları ortaya çıkarabilir. Örneğin, telefonla bildirilen olaylar, e-postayla bildirilenlere göre daha kısa çözüm sürelerine sahip olabilir. Bu bilgi, 'Olay İş Hacmi' Dashboard'unu destekler ve kaynak planlama ve kanal optimizasyon çabalarına yardımcı olur. Neden önemli Olay hacimlerini ve süreç performansını kaynağa göre analiz etmeye yardımcı olur, kanala özgü süreç iyileştirmelerini ve kaynak tahsisini mümkün kılar. Nereden alınır Zendesk Talepler API'si, via.channel alanı. Örnekler webemailapiphone
	SLA Statüsü SlaStatus	Olay için Hizmet Seviyesi Anlaşması'nın (SLA) mevcut durumu.
Açıklama Bu öznitelik, bir olayın tanımlanmış SLA hedeflerini karşılayıp karşılamadığını, ihlal edip etmediğini veya SLA zamanlayıcılarının duraklatılıp duraklatılmadığını gösterir. Zendesk, yapılandırılmış politikalara göre SLA metriklerini otomatik olarak izler. Bu, 'SLA Uyumluluk İzleme' Dashboard'u için kritik bir özniteliktir. Hizmet taahhütlerine karşı performansı doğrudan ölçer. SLA'ların ne zaman ve neden ihlal edildiğini analiz ederek, kuruluşlar süreç zayıflıklarını belirleyebilir ve hizmet güvenilirliğini iyileştirebilir. Doğrudan 'Olay SLA Uyum Oranı' KPI'ını destekler. Neden önemli Hizmet taahhütlerine karşı performansı doğrudan ölçer, SLA ihlallerinin analizini ve uyumluluğu iyileştirmek için proaktif izlemeyi sağlar. Nereden alınır Zendesk Talep Metrikleri API'si (/api/v2/ticket_metrics.json), sla_policy, breached_at gibi alanlardan türetilmiştir. Örnekler AktifDuraklatıldıİhlal EdildiTamamlandı
	Talep Durumu TicketStatus	Olay talebinin olay anındaki durumu; örneğin 'Açık', 'Beklemede' veya 'Çözüldü'.
Açıklama Bu öznitelik, olay talebinin yaşam döngüsündeki farklı noktalarda durumunu yansıtır. Standart Zendesk durumları arasında yeni, açık, beklemede, askıda, çözüldü ve kapalı bulunur. Bu alandaki değişiklikleri izlemek, Process Mining için aktiviteler oluşturmanın birincil yoludur. Talep durumunu analiz etmek, süreci anlamak için temeldir. Olayların 'Beklemede' gibi belirli durumlarda ne kadar zaman harcadığını (genellikle müşteri yanıtını beklediğini gösterir) belirlemeye yardımcı olur. Ayrıca vaka tamamlanmasını tanımlamak ve çözüm sürelerini hesaplamak için de anahtardır. Neden önemli Durum değişikliklerini izlemek, süreç ilerlemesini anlamak, bekleme sürelerini belirlemek ve olay yaşam döngüsünün başlangıç ve bitiş noktalarını tanımlamak için anahtardır. Nereden alınır Zendesk Talepler API'si, status alanı. Değişiklikler Talep Denetimleri API'sinde loglanır. Örnekler yeniopenpendingsolvedkapalı
	Bilet Türü TicketType	Talebin sınıflandırması; örneğin 'Olay', 'Problem', 'Soru' veya 'Görev'.
Açıklama Bu alan, talebi isteğin niteliğine göre kategorize eder. Olay yönetimi süreci özellikle türü 'Olay' olan taleplere odaklanır ve bu, bir BT hizmetinin kalitesinde plansız bir kesintiyi veya azalmayı temsil eder. Analizde bu öznitelik, süreç görünümüne yalnızca olayların dahil edilmesini sağlamak için öncelikli olarak bir filtre olarak kullanılır. Ayrıca, olayları problemlere veya hizmet isteklerine göre ele alma süreçlerini karşılaştırmak için daha geniş ITSM analizi için de kullanılabilir. Neden önemli Verilerin sadece olaylara odaklanacak şekilde filtrelenmesini sağlar, bu da süreç analizinin olay yönetimi yaşam döngüsüyle ilgili olmasını temin eder. Nereden alınır Zendesk Talepler API'si, type alanı. Örnekler olayproblemquestiontask
	Devir Sayısı HandoffCount	Bir olayın farklı bir temsilciye veya gruba yeniden atandığı toplam sayı.
Açıklama Bu hesaplanmış metrik, bir olay için sorumluluğun kaç kez devredildiğini nicelleştirir. Assignee veya AssignedGroup alanındaki her değişiklik, bu sayıyı vaka için artırır. Aktarımlar, olay yönetiminde verimsizlik ve gecikmenin yaygın bir kaynağıdır. Yüksek aktarım sayısı, belirsiz yönlendirme kurallarına, destek ekiplerindeki bilgi boşluklarına veya aşırı karmaşık süreçlere işaret edebilir. Bu metrik, 'Olay Başına Ortalama Aktarım' KPI'ının temelini oluşturur ve 'Aktarım ve Yeniden İşleme Analizi' Dashboard'u için çok önemlidir. Neden önemli Aktarımlardan kaynaklanan süreç sürtünmesini ölçer, bu da çözüm sürelerini uzatan yönlendirme verimsizliklerini ve bilgi eksikliklerini tespit etmeye yardımcı olur. Nereden alınır Bir olay için AssignedGroup veya Assignee alanının kaç kez değiştiği sayılarak hesaplanır. Örnekler 0135
	Etiketler Tags	Olayın kategorize edilmesi ve bağlamı için uygulanan etiketlerin bir listesi.
Açıklama Etiketler, taleplere ek bağlam sağlamak veya kategorizasyon ve yönlendirmeye yardımcı olmak için eklenebilen esnek etiketlerdir. Temsilciler tarafından manuel olarak veya tetikleyiciler ve otomasyonlar aracılığıyla otomatik olarak eklenebilirler. Etiketler, Process Mining analizi 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, analiz için ayrıntılı segmentler oluşturmak amacıyla kullanılabilirler. Bu esneklik, standart talep alanlarının ötesine geçen derinlemesine araştırmalara olanak tanır. Neden önemli Olayları standart alanlarla tek başına mümkün olmayan detaylı, bağlama özel bir analiz yapılmasına olanak tanıyan esnek bir şekilde kategorize etme ve filtreleme imkanı sunar. Nereden alınır Zendesk Talepler API'si, tags alanı. Örnekler vip_userağ_sorunuoutage_20231027fatura_ilgili
	Gönderen Submitter	Olayı orijinal olarak bildiren son kullanıcı veya sistem.
Açıklama Bu öznitelik, talebi oluşturan kişiyi veya kuruluşu tanımlar. Bu, talep edenden farklıdır, çünkü bir temsilci başkası adına bir talep oluşturabilir. Analizde, gönderici, sorunları kimin bildirdiğini anlamak için kullanılabilir. Kuruluş verileriyle birleştirildiğinde, belirli müşterilerin veya kullanıcı gruplarının yüksek hacimli olaylar yaşayıp yaşamadığını belirlemeye yardımcı olabilir. Bu, proaktif destek girişimlerine veya eğitim çabalarına rehberlik edebilir. Neden önemli Olay raporunun kaynağını tanımlar, bu da belirli kullanıcılar, departmanlar veya otomatik sistemlerle ilgili kalıpları bulmak için analiz edilebilir. Nereden alınır Zendesk Talepler API'si, submitter_id alanı. Örnekler alice.jones@example.combob.williams@example.comSistem Monitörü
	İlk Temas Çözünürlüğü mü? IsFirstContactResolution	Eğer olay, herhangi bir devir olmaksızın ilk atanan temsilci veya grup tarafından çözüldüyse doğru olan bir boolean bayrağı.
Açıklama İlk İletişim Çözümü (FCR), destek merkezi verimliliği ve müşteri memnuniyeti için kritik bir metriktir. Bu hesaplanmış nitelik, başka bir temsilciye veya ekibe yeniden atanmadan çözülen olayları işaretler. Mantık genellikle, biletin başlangıçtaki temsilciye ve gruba atanmışken 'Çözüldü' durumuna ulaşıp ulaşmadığını kontrol eder. Process Mining'de bu, FCR oranının doğrudan hesaplanmasına ve FCR olaylarının süreç yollarını, yükseltme gerektiren olaylarınkilerle karşılaştırmaya olanak tanır; bu da ön saflardaki desteği güçlendirme fırsatlarını belirlemeye yardımcı olur. Neden önemli İlk destek temas noktasının verimliliğini doğrudan ölçer ve çözümü sürecin daha erken aşamalarına kaydırma fırsatlarını belirlemeye yardımcı olur. Nereden alınır Hesaplanmış boolean bayrağı. Bilet durumu 'çözüldü' veya 'kapalı' ise ve olayın yaşam döngüsü boyunca yalnızca bir benzersiz atanan veya atanan grup varsa doğru olur. Örnekler truefalse
	İşlem Süresi ProcessingTime	Tek bir aktivitenin süresi, bir görev üzerinde aktif olarak çalışılan zamanı temsil eder.
Açıklama Bu metrik, bir aktivitenin başlangıcından sonuna kadar geçen süreyi ölçer. Event Log'daki her satır için EventEndTime ve EventTimestamp arasındaki fark olarak hesaplanır. İşlem süresi (Processing time), aynı zamanda aktivite süresi olarak da bilinir, aktif çalışma süresi ile boşta kalma veya bekleme süresi arasında ayrım yapmaya yardımcı olur. 'Darboğaz Aktiviteleri Genel Bakışı' Dashboard'unda, belirli aktiviteler için yüksek ortalama işlem süreleri, karmaşık, zaman alıcı görevlere işaret edebilir. Bu, görevler arasındaki gecikmeleri temsil eden bekleme süresinden farklıdır. Neden önemli Belirli aktiviteler için aktif çalışma süresini ölçer, doğal olarak zaman alıcı olan ve basitleştirme veya otomasyon adayı olan görevleri belirlemeye yardımcı olur. Nereden alınır Her aktivite için EventEndTime ve EventTimestamp arasındaki fark olarak hesaplanır. Örnekler 30018003600
	Kök Neden Kategorisi RootCauseCategory	Olayın temel kök nedeninin üst düzey kategorisi.
Açıklama Bu öznitelik, bir olayın neden meydana geldiğinin temel nedenini sınıflandırmak için kullanılır. Genellikle olay yaşam döngüsünün sonuna doğru, genellikle bir otopsi veya problem yönetimi sürecinin bir parçası olarak yakalanır ve özel bir alanda saklanır. Bu veri, 'Kök Neden Tespit Doğruluğu' Dashboard'u ve 'RCA Kapsamı' KPI'ı için esastır. Olayları kök nedene göre analiz etmek, tekrarlayan sorunları belirlemeye yardımcı olur, kalıcı düzeltmeler uygulamak ve gelecekteki olay hacmini azaltmak için çabalara rehberlik eder. Odağı reaktif yangın söndürmeden proaktif sorun önlemeye kaydırır. Neden önemli Olay nedenlerini kategorize ederek proaktif problem yönetimini sağlar, eğilimleri belirlemeye ve gelecekteki olayları önlemeye yardımcı olur. Nereden alınır Bu genellikle özel bir talep alanıdır. Zendesk Yönetim Merkezi'ndeki Talep Alanları 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ı tarafından verilen memnuniyet derecesi.
Açıklama Bu öznitelik, müşterinin destek deneyimi hakkındaki geri bildirimlerini yakalar ve genellikle talep çözüldükten sonra bir anket aracılığıyla toplanır. Zendesk'teki yaygın derecelendirmeler 'İyi' veya 'Kötü' şeklindedir. Süreç verimliliğinin doğrudan bir ölçüsü olmasa da, memnuniyet derecelendirmeleri kritik bir sonuç metriği sağlar. Process Mining'de bu, hangi çözüm yollarının daha yüksek müşteri memnuniyetine yol açtığını anlamak için süreç varyantlarıyla ilişkilendirilebilir. Örneğin, daha fazla aktarıma sahip olaylar daha düşük derecelendirme mi alır? Neden önemli Süreç performansının kullanıcı memnuniyetini nasıl etkilediğini anlamak için süreç özellikleriyle ilişkilendirilebilecek önemli bir sonuç metriği sunar. Nereden alınır Zendesk Talep Metrikleri API'si (/api/v2/ticket_metrics.json), satisfaction_rating.score alanı. Örnekler goodbadofferedunoffered
	Müşteri Organizasyonu Organization	Olay talebinde bulunan kişinin ait olduğu organizasyon veya şirket.
Açıklama Bu öznitelik, bir olayı müşterinin kuruluşuyla ilişkilendirir. Hizmet seviyelerinin ve destek süreçlerinin müşteriye göre değişebildiği B2B destek ortamları için esastır. Olayları kuruluşa göre analiz etmek, destek ekiplerinin müşteri sağlığını izlemesine, belirli müşterileri etkileyen tekrarlayan sorunları belirlemesine ve sözleşme yükümlülüklerinin karşılandığından emin olmasına olanak tanır. Dashboard'ları ve raporları filtreleyerek performansa müşteri odaklı bir bakış açısı sağlamak için önemli bir boyuttur. Neden önemli Müşteriye özel analizleri mümkün kılar; hizmet seviyelerini izlemeye, ana hesaplar için eğilimleri belirlemeye ve müşteri ilişkilerini etkili bir şekilde yönetmeye yardımcı olur. Nereden alınır Zendesk Talepler API'si, organization_id alanı. Örnekler `Global Tech Inc.`Çözümler YenileData Corp
	Otomatikleştirildi mi? IsAutomated	Bir aktivitenin otomatik bir sistem mi yoksa bir insan aracısı tarafından mı gerçekleştirildiğini gösteren bir boolean bayrağı.
Açıklama Bu türetilmiş öznitelik, insan kullanıcılar tarafından yürütülen olaylar ile sistem otomasyonları, tetikleyiciler veya API entegrasyonları tarafından gerçekleştirilen olaylar arasında ayrım yapmaya yardımcı olur. Genellikle bir olayın yazarının bilinen bir sistem kullanıcısı olup olmadığı kontrol edilerek belirlenir. Otomasyon seviyesini anlamak, modern süreç analizi için çok önemlidir. Otomasyon kurallarının etkinliğini değerlendirmeye, otomatikleştirilebilecek manuel görevleri belirlemeye ve otomasyonun verimlilik ve çözüm süreleri üzerindeki etkisini ölçmeye yardımcı olur. Bu öznitelik, otomatik ve manuel aktivitelerin süreç akışlarını karşılaştırmak için kullanılabilir. Neden önemli İnsan ve sistem eylemleri arasında ayrım yapar, bu da otomasyonun süreç verimliliği üzerindeki etkisini analiz etmek ve yeni otomasyon fırsatlarını belirlemek için temeldir. Nereden alınır Olay yazarının (Ticket Audits API'sindeki author_id) bilinen bir sistem veya otomasyon kullanıcısına karşılık gelip gelmediği kontrol edilerek türetilir. Örnekler truefalse
	Şiddet Severity	Olayın işletme üzerindeki etki düzeyi.
Açıklama Ciddiyet (Severity), bir olayın iş üzerindeki etkisini tanımlar ve genellikle öncelik ile birlikte genel aciliyeti belirlemek için kullanılır. Tipik olarak Zendesk'te özel bir alan olarak yapılandırılır. Ciddiyetin analizi, ele alınan olayların kritikliğini anlamaya yardımcı olur. 'SLA Uyumluluk İzleme' ve 'Önceliklendirme Etkinliği Metrikleri' gibi Dashboard'larda verileri segmentlere ayırmak için önemli bir boyuttur. Farklı ciddiyet seviyeleri için süreç akışlarını karşılaştırmak, yüksek ciddiyetli olayların uygun hız ve kaynaklarla ele alınıp alınmadığını ortaya çıkarabilir. Neden önemli Bir olayın iş üzerindeki etkisini gösterir; en kritik sorunlara odaklanan analizi mümkün kılar ve bunların verimli bir şekilde çözülmesini sağlar. Nereden alınır Bu genellikle özel bir alandır. Zendesk Yönetim Merkezi'ndeki Talep Alanları yapılandırmasını kontrol edin. Örnekler 1 - Kritik2 - Yüksek3 - Orta4 - Düşük
	Vaka Süresi CaseDuration	Olayın oluşturulmasından nihai kapanışına kadar geçen toplam süre.
Açıklama Bu hesaplanmış metrik, tek bir olay için uçtan uca döngü süresini temsil eder. İlk olayın ('Olay Oluşturuldu' gibi) zaman damgası ile en son olayın ('Olay Kapatıldı' gibi) zaman damgası arasındaki fark alınarak hesaplanır. 過程中，此ID對於重建每個事件的端到端旅程至關重要。它可以聚合事件數據來追蹤總解決時間、交接次數以及各個事件的服務水平協議遵守情況等指標。通過此ID對事件進行分組，分析師可以視覺化流程流，識別常見路徑，並檢測與標準程序的偏差。Vaka Süresi (Case Duration), genel süreç verimliliği için birincil bir Temel Performans Göstergesi (KPI)'dir. Dashboard'larda ortalama döngü sürelerini göstermek, uzun süreli vakaları belirlemek ve zaman içindeki eğilimleri analiz etmek için yoğun bir şekilde kullanılır. Sürecin olayları ne kadar hızlı ele alıp çözebileceğine dair üst düzey bir ölçüm sağlar. Neden önemli Bu, genel süreç hızını ölçmek ve uzun çözüm sürelerine katkıda bulunan faktörleri belirlemek için kritik bir KPI'dır. Nereden alınır Her Olay Kimliği için son olay zaman damgası ile ilk olay zaman damgası arasındaki fark bulunarak hesaplanır. Örnekler 25920060480086400

Gerekli Önerilen İsteğe Bağlı

Olay Yönetimi Faaliyetleri

Bunlar, doğru keşif ve analiz için event log'unuza kaydetmeniz gereken kritik süreç adımları ve kilometre taşlarıdır.

6 Önerilen 7 İsteğe Bağlı

	Aktivite	Açıklama
	Bilet Temsilciye Atandı	Bu aktivite, bir talebin ele alınmak üzere belirli bir temsilciye atanmasıyla gerçekleşir. Bu, talebin denetim geçmişine kaydedilen açık bir olaydır ve bir bireyin sahiplendiğini gösterir.
Neden önemli Bu kilometre taşı, ilk atamaya kadar geçen süreyi ölçmek için esastır ve aktarımları, yeniden işlemeyi ve İlk Temas Çözümü oranlarını analiz etmenin temelini oluşturur. Nereden alınır Bilet denetim günlüğünden, 'assignee_id' alanı doldurulduğunda veya değiştiğinde alınır. İlk atama, KPI hesaplaması için önemli bir kilometre taşıdır. Yakala Bilet denetim günlüğündeki 'assignee_id' alanındaki bir 'Değişiklik' olayı ile tanımlanır. Event tipi explicit
	Durum Açık Olarak Değiştirildi	Bir temsilcinin olay üzerinde aktif olarak çalışmaya başladığını gösterir. Bu aktivite genellikle biletin 'durum' alanının 'yeni'den 'açık'a değişmesinden çıkarılır ve bu, araştırma ve teşhis aşamasının başlangıcını işaret eder.
Neden önemli Bu olay, kuyrukta beklemekten aktif çalışmaya geçişi işaret eder. Taleplerin 'yeni' durumunda 'açık' durumuna geçmeden önce geçirdiği süre, ilk yanıt süresi için önemli bir metriktir. Nereden alınır Bilet denetim günlüğünden, 'status' alanının yeni değerinin 'open' ve önceki değerinin 'new' olduğu bir 'Değişiklik' olayı tanımlanarak çıkarılır. Yakala Durum alanının 'new'dan 'open'a değişmesinden çıkarılır. Event tipi inferred
	Olay Çözüldü	Bu önemli kilometre taşı, bir temsilcinin bir çözüm uygulayıp talebi 'çözüldü' olarak işaretlemesiyle gerçekleşir. Bu, talep denetim logunda bir durum değişikliği olarak yakalanan açık bir eylemdir.
Neden önemli Bu, birincil çözüm aktivitesi ve çözüme ulaşma süresini ölçmek için kritik bir noktadır. Bu olay ile 'Olay Kapatıldı' arasındaki süre, kullanıcı onayı veya otomatik kapanış dönemini temsil eder. Nereden alınır Bilet denetim günlüğünden, 'status' alanının yeni değerinin 'solved' olduğu bir 'Değişiklik' olayı aracılığıyla alınır. Yakala 'status' alanının 'solved' olarak değiştiği bir 'Değişiklik' olayı ile tanımlanır. Event tipi explicit
	Olay Kapatıldı	Bilet kalıcı olarak kapatıldığında olay yaşam döngüsünün sonunu işaretler. Zendesk'te bu durum genellikle çözüldükten sonra belirli bir süre geçtikten sonra otomatik olarak gerçekleşir ve nihai bir durum değişikliği olarak yakalanır.
Neden önemli Bu, süreç için kesin son aktivitedir. Toplam süreç süresi, 'Olay Oluşturuldu' olayından bu olaya kadar hesaplanarak döngü süresinin uçtan uca bir görünümünü sağlar. Nereden alınır Bilet denetim günlüğünden, 'status' alanının yeni değerinin 'closed' olduğu bir 'Değişiklik' olayı aracılığıyla alınır. Yakala 'status' alanının 'closed' olarak değiştiği bir 'Değişiklik' olayı ile tanımlanır. Event tipi explicit
	Olay Oluşturuldu	Zendesk'te yeni bir bilet oluşturulduğunda olay yaşam döngüsünün başlangıcını işaretler. Bu olay, her vaka için başlangıç noktası olarak hizmet veren Zendesk'in bilet oluşturma denetim günlüğü aracılığıyla açıkça yakalanır.
Neden önemli Bu, birincil başlangıç aktivitesidir. Bu olaydan diğerlerine kadar geçen süreyi analiz etmek, genel talep yaşam döngüsü süresini ve ilk yanıt sürelerini ölçmek için çok önemlidir. Nereden alınır Bu, Zendesk talep denetim loglarında yakalanan açık bir olaydır. Her yeni talep, karşılık gelen bir zaman damgası ile bir 'Oluştur' olayı üretir. Yakala Doğrudan denetim günlüğündeki bilet oluşturma olayından. Event tipi explicit
	Talep Yeniden Atandı	Bilet sahipliği, ilk atamadan sonra bir temsilciden veya gruptan diğerine devredildiğinde meydana gelir. Bu, biletin denetim geçmişinde izlenen açık bir olaydır.
Neden önemli Yeniden atamalar, aktarımları ve yeniden işleme süreçlerini analiz etmek için kritiktir. Yüksek yeniden atama sıklığı genellikle yanlış başlangıç yönlendirmesine, karmaşık sorunlara veya süreç darboğazlarına işaret eder. Nereden alınır Bilet denetim günlüğünden, 'assignee_id' veya 'group_id' alanının ilk kez doldurulmasından sonraki bir 'Değişiklik' olayını tanımlayarak alınır. Yakala 'assignee_id' veya 'group_id' alanı için sonraki bir 'Değişiklik' olayı ile tanımlanır. Event tipi explicit
	Dahili Not Eklendi	Bu aktivite, bir temsilcinin diğer ekip üyeleri için talebe özel bir not eklediği iç işbirliğini ifade eder. Bir yorumun herkese açık olmadığı işaretlendiğinde açıkça kaydedilir.
Neden önemli Dahili notların analizi, işbirliği gerektiren karmaşık sorunlara ilişkin içgörüler sağlayabilir, ancak aşırı sayıda not, bilgi eksikliklerine veya süreç verimsizliklerine işaret edebilir. Nereden alınır Bilet yorum verilerinden alınır. Bir yorum, 'public' niteliği yanlış olduğunda dahili bir not olarak tanımlanır. Yakala 'public: false' özellikli yeni bir yorum bilete eklendiğinde kaydedilen olay. Event tipi explicit
	Durum Beklemede Olarak Değiştirildi	Talep sahibinden yanıt beklenirken sürecin duraklatıldığını gösterir. Bu olay, biletin 'durum' alanının 'beklemede' olarak değişmesinden çıkarılır.
Neden önemli Bu aktivite, Kullanıcı Onayı Bekleme Süresini hesaplamak için çok önemlidir. Bu durumdaki uzun süreler, genel çözüm süresini önemli ölçüde artırabilir ve iletişim gecikmelerini vurgulayabilir. Nereden alınır Bilet denetim günlüğünden, 'status' alanının yeni değerinin 'pending' olduğu bir 'Değişiklik' olayı tanımlanarak çıkarılır. Yakala Durum alanının 'pending'e değişmesinden çıkarılır. Event tipi inferred
	Herkese Açık Yanıt Gönderildi	Bir destek temsilcisinden son kullanıcıya gönderilen bir iletişimi temsil eder. Bu, Zendesk'te bir talebe herkese açık bir yorum eklendiğinde yakalanan açık bir olaydır.
Neden önemli Herkese açık yanıtları izlemek, iletişim sıklığını anlamak için önemlidir ve kullanıcı onayı gecikmelerini analiz ederken zaman çizelgesinin önemli bir parçası olabilir. Nereden alınır Bilet yorum verilerinden alınır. Bir yorum, 'public' niteliği doğru olduğunda herkese açık olarak tanımlanır. Yakala 'public: true' özellikli yeni bir yorum bilete eklendiğinde kaydedilen olay. Event tipi explicit
	Kullanıcı Memnuniyeti Derecelendirildi	Son kullanıcının aldığı destek için bir memnuniyet derecesi verdiği noktayı temsil eder. Bu, bir talep çözüldükten sonra Zendesk'te yakalanan açık bir olaydır.
Neden önemli Memnuniyet derecelendirmelerini analiz etmek, temsilci performansı ve süreç etkinliği hakkında kritik geri bildirimler sağlar, süreç metriklerini müşteri sonuçlarına bağlar. Nereden alınır Biletle ilişkili memnuniyet derecelendirme verilerinden alınır. Bu genellikle bir puan ('iyi' veya 'kötü') ve isteğe bağlı bir yorum içerir. Yakala Bilet için bir memnuniyet derecelendirmesi gönderildiğinde kaydedilen olay. Event tipi explicit
	Öncelik Belirlendi	Bir olayın öncelik seviyesi (örn. Düşük, Normal, Yüksek, Acil) tanımlanır. Bu, açık bir değişiklik olayı olarak kaydedilir ve bilet için aciliyeti ve gerekli yanıt süresini belirler.
Neden önemli Önceliğin ne zaman ve nasıl ayarlandığını izlemek, 'Önceliklendirme Etkinliği Metrikleri' Dashboard'u için hayati önem taşır ve kritik sorunların hızla ele alınmasını sağlar. Nereden alınır Bilet denetim günlüğündeki 'öncelik' alanında gerçekleşen bir 'Değişiklik' olayından alınır. Sonraki değişiklikler de Öncelik Değişim Oranı KPI'ını ölçmek için izlenebilir. Yakala Bilet denetim günlüğündeki 'priority' alanındaki bir 'Değişiklik' olayı ile tanımlanır. Event tipi explicit
	SLA Hedefi İhlal Edildi	Bir biletin ilk yanıt süresi veya çözüm süresi gibi tanımlanmış bir Hizmet Seviyesi Anlaşması'nı karşılayamadığı anı işaretler. Bu olay, SLA politikası tanımları ve bilet güncelleme zaman damgalarına göre hesaplanır.
Neden önemli Bu olay, SLA uyumluluk izlemeyi doğrudan destekler. İhlallerin ne zaman ve neden meydana geldiğini belirlemek, hizmet güvenilirliğini ve müşteri güvenini artırmak için temeldir. Nereden alınır Bu hesaplanmış bir olaydır. Bir taleple ilişkili 'sla_policy_metrics' verileri analiz edilerek, her bir SLA hedefi için 'breached_at' zaman damgası kullanılarak türetilebilir. Yakala Biletin SLA metrik verilerindeki 'breached_at' zaman damgasından türetilir. Event tipi calculated
	Talep Gruba Atandı	Bir olayın belirli bir destek grubuna ilk yönlendirmesini veya triyajını temsil eder. Bu genellikle sorumluluk atamanın ilk adımıdır ve talebin denetim geçmişinde açık bir değişiklik olayı olarak kaydedilir.
Neden önemli Grup atamalarını izlemek, ilk triyaj sürecinin verimliliğini analiz etmeye ve bir talep doğru ekibe yönlendirilmeden önceki gecikmeleri belirlemeye yardımcı olur. Nereden alınır Bilet denetim günlüğünden, 'group_id' alanı her ayarlandığında veya değiştiğinde alınır. Oluşturulduktan sonraki bu değişikliğin ilk örneği, ilk atamadır. Yakala Bilet denetim günlüğündeki 'group_id' alanındaki bir 'Değişiklik' olayı ile tanımlanır. Event tipi explicit

Önerilen İsteğe Bağlı

Veri Çekim Kılavuzları

Verilerinizi Zendesk Support'tan Nasıl Alırsınız

Adımlar

Zendesk Explore'a Erişin: Zendesk Support örneğinize, Zendesk Explore'da rapor oluşturma ve yönetme izinlerine sahip bir kullanıcı hesabıyla giriş yapın.
Yeni Bir Rapor Oluşturun: Explore modülüne gidin. Sol gezinme çubuğundaki 'Raporlar' simgesine tıklayın, ardından 'Yeni rapor' düğmesine tıklayın.
Veri Kümesini Seçin: 'Veri kümesi seçin' penceresinde, Support: Ticket updates [default] veri kümesini seçin. Bu veri kümesi, bir olay günlüğü oluşturmak için gerekli olan her bilet değişikliğinin denetim geçmişini içerir.
Başlangıç Niteliklerini (Sütunlar) Ekleyin: Rapor oluşturucuda, 'Satırlar' bölümüne gidin. 'Ekle'ye tıklayın ve aşağıdaki nitelikleri seçin. Bunlar olay günlüğünüzün sütunlarını oluşturacaktır: Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value, Comment public.
Hesaplanmış Nitelikler Oluşturun: Bu en kritik adımdır. 'Hesaplamalar' menüsüne (beher simgesi) gidin ve 'Standart hesaplanmış nitelik' seçeneğini belirleyin. Aşağıdaki 'Sorgu' bölümünde tanımlanan üç niteliği oluşturun: ActivityName, SourceSystem ve LastDataUpdate. Sağlanan formülleri tam olarak kopyalamanız gerekecektir.
Rapor Sütunlarını İyileştirin: Yeni oluşturduğunuz hesaplanmış nitelikleri (ActivityName, SourceSystem, LastDataUpdate) 'Satırlar' bölümüne ekleyin. Görünümü temizlemek için ActivityName'i oluşturmak için kullanılan ham alanları (Changes - Field name, Changes - Previous value, Changes - New value, Comment public) artık kaldırabilirsiniz.
Rapor Filtreleri Ekleyin: 'Filtreler' bölümüne gidin ve 'Ekle'ye tıklayın. 'Update - Date' için bir filtre ekleyin ve uygun bir tarih aralığı seçin (örn. son 3 ay). Hesaplanan niteliğiniz ActivityName üzerinde başka bir filtre ekleyin ve istenen bir etkinliğe karşılık gelmeyen bilet güncellemelerini kaldırmak için boş değerleri hariç tutun.
Raporu Çalıştırın ve İnceleyin: Zendesk Explore, nitelikler ve filtreler ekledikçe raporu otomatik olarak güncelleyecektir. Satırların ve sütunların beklendiği gibi göründüğünden emin olmak için veri tablosunu inceleyin. Rapor, olay başına bir satır göstermelidir.
Verileri CSV'ye Aktarın: Rapor tamamlandığında, sağ üst köşedeki 'Dışa Aktar' düğmesine tıklayın ve 'CSV'yi seçin. Zendesk, CSV dosyasını oluşturacak ve indirecektir.
Yükleme İçin Hazırlık: Dışa aktarılan CSV dosyasını açın. Sütun başlıklarını Process Mining aracınız için gerekli nitelik adlarıyla eşleşecek şekilde yeniden adlandırın (örn. 'Ticket ID'yi TicketId, 'Update - Timestamp'ı EventTimestamp olarak yeniden adlandırın). Zaman damgalarının tarih biçiminin ISO 8601 uyumlu olduğundan emin olun. Dosya artık yüklemeye hazırdır.

Konfigürasyon

Zendesk Veri Kümesi: Rapor, Support: Ticket updates [default] veri kümesi üzerine inşa edilmelidir. Bu, süreci olay bazında yeniden yapılandırmak için gereken ayrıntılı denetim geçmişini sağlayan tek standart veri kümesidir.
Tarih Aralığı Filtreleme: Veri hacmini sınırlamak için bir tarih filtresi uygulamak çok önemlidir. Birincil filtreniz olarak 'Update - Date' niteliğini kullanın. İlk analiz için genellikle 3-6 aylık veri aralığı önerilir.
Aktivite Filtresi: ActivityName hesaplanmış niteliğini oluşturduktan sonra, bu değerin boş olduğu satırları hariç tutmak için raporu filtrelemeniz gerekir. Bu, olay günlüğünüzdeki alakasız bilet değişikliklerini (örn. sistem güncellemeleri, etiket değişiklikleri) kaldırır.
Hesaplanmış Nitelikler: Bu çıkarımın mantığı, ham bilet alanı değişikliklerini insan tarafından okunabilir aktivite adlarına dönüştürmek için standart bir hesaplanmış niteliğe büyük ölçüde dayanır. Formüldeki hassasiyet çok önemlidir.
Ön Koşullar: Raporu çalıştıran kullanıcının Zendesk Explore'da en az 'Görüntüleyici' rolüne sahip olması gerekir. Raporu oluşturmak ve kaydetmek için 'Düzenleyici' veya 'Yönetici' izinleri gereklidir.

a Örnek Sorgu config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

Adımlar

Ön Koşullar: Sisteminizde Python 3.6+ ile birlikte requests ve pandas kütüphanelerinin kurulu olduğundan emin olun. Bunları pip kullanarak yükleyebilirsiniz: pip install requests pandas.
Zendesk API Anahtarı Oluşturun: Yönetici olarak Zendesk Support örneğinize giriş yapın. Yönetici Merkezi > Uygulamalar ve entegrasyonlar > API'ler > Zendesk API'leri yolunu izleyin. "API Anahtarları" bölümünün altında, yeni bir aktif API anahtarı ekleyin ve oluşturulan anahtar dizesini güvenli bir şekilde kaydedin.
Python Betiğini Yapılandırın: Yeni bir Python dosyası oluşturun (örn. extract_zendesk_logs.py) ve sağlanan betiği içine kopyalayın. Betiğin üst kısmındaki yer tutucu değişkenleri (ZENDESK_SUBDOMAIN, ZENDESK_EMAIL ve ZENDESK_API_TOKEN) kendi kimlik bilgilerinizle güncelleyin. İstenen veri çıkarma döneminin başlangıcını tanımlamak için START_TIMESTAMP'ı ayarlayın (bir Unix epoch zaman damgası).
API Uç Noktalarını Anlayın: Betik öncelikle iki Zendesk API uç noktasını kullanır. incremental/tickets/cursor.json uç noktası, START_TIMESTAMP'tan bu yana güncellenen tüm biletleri verimli bir şekilde çekmek için kullanılır. Her bilet için betik daha sonra tickets/{ticket_id}/audits.json uç noktasını çağırarak her değişiklik ve olayın ayrıntılı bir geçmişini alır.
Betiği Çalıştırın: Betiği terminalinizden python extract_zendesk_logs.py komutunu kullanarak çalıştırın. Betik, Zendesk API'sinden veri çekmeye başlayacaktır.
Betik İlerlemesini İzleyin: Betik, işlenen bilet sayısını konsola yazdıracak ve ilerlemesini izlemenize olanak tanıyacaktır. Tarih aralığına ve bilet hacmine bağlı olarak bu önemli miktarda zaman alabilir.
Veri Çekme ve Sayfalama: Betik, API sayfalama işlemini otomatik olarak ele alır. İlk bilet dışa aktarma URL'si ile başlar ve döneme ait tüm biletler alınana kadar her API yanıtında sağlanan after_url'yi takip eder.
Olay Dönüşümü: Her bilet için betik, denetim geçmişi boyunca yineler. Her denetim olayını ayrıştırır, Zendesk'in dahili olay türlerini (Create, Change, Comment gibi) gerekli iş etkinlikleriyle (Incident Created, Status Changed to Open, Public Reply Sent gibi) eşleştirir.
SLA Verilerini İşleme: Betik, çözülen her bilet için SLA metriklerini çekmek üzere get_sla_breach_events adlı özel bir fonksiyon içerir. Bunun nedeni, SLA ihlallerinin denetim günlüğünde standart olaylar olmamasıdır. Bu fonksiyon, SLA politikası uygulama ayrıntılarını almak için ek bir API çağrısı yapar.
Olay Günlüğü Oluşturun: Tüm biletler işlendikten sonra, betik çıkarılan olayları bir pandas DataFrame'inde derler ve son olay günlüğünü betiğin çalıştırıldığı aynı dizinde zendesk_incident_event_log.csv adlı bir CSV dosyası olarak kaydeder.
Yükleme İçin Hazırlık: Oluşturulan CSV dosyasını doğruluk açısından inceleyin. Bu dosya artık analiz için doğrudan ProcessMind'e yüklenecek gerekli formattadır.

Konfigürasyon

Zendesk API Kimlik Bilgileri: Zendesk alt alan adınızı, bir yönetici veya temsilci hesabıyla ilişkili e-posta adresini ve geçerli bir API anahtarını sağlamanız gerekmektedir. Bu kimlik bilgilerini güvenli bir şekilde saklayın ve üretim kullanımı için sürüm kontrollü betiklere gömmeyin.
Başlangıç Zaman Damgası (START_TIMESTAMP): Bu tam sayı değeri, veri çıkarmanın başlangıç noktasını belirler. Bir Unix epoch zaman damgası olmalıdır. Sistemi aşırı yüklemeden anlamlı miktarda veri toplamak için geçmiş 3-6 aylık bir başlangıç noktası önerilir. Belirli bir tarih için doğru zaman damgasını almak üzere çevrimiçi bir dönüştürücü kullanabilirsiniz.
API Hız Sınırı: Betik çok sayıda API çağrısı yapar. Zendesk, plana göre değişen hız sınırları uygular. Betik orta veri hacimleri için işlevsel olsa da, çok büyük örnekler için hız sınırına takılmamak ve 429 hatası almamak adına döngüler içine time.sleep() çağrıları eklemeniz gerekebilir.
Gerekli Python Kütüphaneleri: Betik, API çağrıları yapmak için requests kütüphanesine ve veri manipülasyonu ile CSV dışa aktarımı için pandas kütüphanesine bağlıdır. Bunların Python ortamınızda yüklü olduğundan emin olun.
Kullanıcı İzinleri: API anahtarıyla ilişkili kullanıcı hesabının, denetimler ve bilet metrikleri dahil olmak üzere bilet verilerini okumak için yeterli izinlere sahip olması gerekir.

a Örnek Sorgu python

import requests
import pandas as pd
import time
import os
from datetime import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
START_TIMESTAMP = 1672531200 

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
AUTH = (fclass="hl-string">"{ZENDESK_EMAIL}/token", ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    audits_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

if __name__ == class="hl-string">"__main__":
    main()

Adımlar

Ön Koşullar: Sisteminizde Python 3.6+ ile birlikte requests ve pandas kütüphanelerinin kurulu olduğundan emin olun. Bunları pip kullanarak yükleyebilirsiniz: pip install requests pandas.
Zendesk API Anahtarı Oluşturun: Yönetici olarak Zendesk Support örneğinize giriş yapın. Yönetici Merkezi > Uygulamalar ve entegrasyonlar > API'ler > Zendesk API'leri yolunu izleyin. "API Anahtarları" bölümünün altında, yeni bir aktif API anahtarı ekleyin ve oluşturulan anahtar dizesini güvenli bir şekilde kaydedin.
Python Betiğini Yapılandırın: Yeni bir Python dosyası oluşturun (örn. extract_zendesk_logs.py) ve sağlanan betiği içine kopyalayın. Betiğin üst kısmındaki yer tutucu değişkenleri (ZENDESK_SUBDOMAIN, ZENDESK_EMAIL ve ZENDESK_API_TOKEN) kendi kimlik bilgilerinizle güncelleyin. İstenen veri çıkarma döneminin başlangıcını tanımlamak için START_TIMESTAMP'ı ayarlayın (bir Unix epoch zaman damgası).
API Uç Noktalarını Anlayın: Betik öncelikle iki Zendesk API uç noktasını kullanır. incremental/tickets/cursor.json uç noktası, START_TIMESTAMP'tan bu yana güncellenen tüm biletleri verimli bir şekilde çekmek için kullanılır. Her bilet için betik daha sonra tickets/{ticket_id}/audits.json uç noktasını çağırarak her değişiklik ve olayın ayrıntılı bir geçmişini alır.
Betiği Çalıştırın: Betiği terminalinizden python extract_zendesk_logs.py komutunu kullanarak çalıştırın. Betik, Zendesk API'sinden veri çekmeye başlayacaktır.
Betik İlerlemesini İzleyin: Betik, işlenen bilet sayısını konsola yazdıracak ve ilerlemesini izlemenize olanak tanıyacaktır. Tarih aralığına ve bilet hacmine bağlı olarak bu önemli miktarda zaman alabilir.
Veri Çekme ve Sayfalama: Betik, API sayfalama işlemini otomatik olarak ele alır. İlk bilet dışa aktarma URL'si ile başlar ve döneme ait tüm biletler alınana kadar her API yanıtında sağlanan after_url'yi takip eder.
Olay Dönüşümü: Her bilet için betik, denetim geçmişi boyunca yineler. Her denetim olayını ayrıştırır, Zendesk'in dahili olay türlerini (Create, Change, Comment gibi) gerekli iş etkinlikleriyle (Incident Created, Status Changed to Open, Public Reply Sent gibi) eşleştirir.
SLA Verilerini İşleme: Betik, çözülen her bilet için SLA metriklerini çekmek üzere get_sla_breach_events adlı özel bir fonksiyon içerir. Bunun nedeni, SLA ihlallerinin denetim günlüğünde standart olaylar olmamasıdır. Bu fonksiyon, SLA politikası uygulama ayrıntılarını almak için ek bir API çağrısı yapar.
Olay Günlüğü Oluşturun: Tüm biletler işlendikten sonra, betik çıkarılan olayları bir pandas DataFrame'inde derler ve son olay günlüğünü betiğin çalıştırıldığı aynı dizinde zendesk_incident_event_log.csv adlı bir CSV dosyası olarak kaydeder.
Yükleme İçin Hazırlık: Oluşturulan CSV dosyasını doğruluk açısından inceleyin. Bu dosya artık analiz için doğrudan ProcessMind'e yüklenecek gerekli formattadır.

Konfigürasyon

Zendesk API Kimlik Bilgileri: Zendesk alt alan adınızı, bir yönetici veya temsilci hesabıyla ilişkili e-posta adresini ve geçerli bir API anahtarını sağlamanız gerekmektedir. Bu kimlik bilgilerini güvenli bir şekilde saklayın ve üretim kullanımı için sürüm kontrollü betiklere gömmeyin.
Başlangıç Zaman Damgası (START_TIMESTAMP): Bu tam sayı değeri, veri çıkarmanın başlangıç noktasını belirler. Bir Unix epoch zaman damgası olmalıdır. Sistemi aşırı yüklemeden anlamlı miktarda veri toplamak için geçmiş 3-6 aylık bir başlangıç noktası önerilir. Belirli bir tarih için doğru zaman damgasını almak üzere çevrimiçi bir dönüştürücü kullanabilirsiniz.
API Hız Sınırı: Betik çok sayıda API çağrısı yapar. Zendesk, plana göre değişen hız sınırları uygular. Betik orta veri hacimleri için işlevsel olsa da, çok büyük örnekler için hız sınırına takılmamak ve 429 hatası almamak adına döngüler içine time.sleep() çağrıları eklemeniz gerekebilir.
Gerekli Python Kütüphaneleri: Betik, API çağrıları yapmak için requests kütüphanesine ve veri manipülasyonu ile CSV dışa aktarımı için pandas kütüphanesine bağlıdır. Bunların Python ortamınızda yüklü olduğundan emin olun.
Kullanıcı İzinleri: API anahtarıyla ilişkili kullanıcı hesabının, denetimler ve bilet metrikleri dahil olmak üzere bilet verilerini okumak için yeterli izinlere sahip olması gerekir.

a Örnek Sorgu python

import requests
import pandas as pd
import time
import os
from datetime import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
START_TIMESTAMP = 1672531200 

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
AUTH = (fclass="hl-string">"{ZENDESK_EMAIL}/token", ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    audits_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

if __name__ == class="hl-string">"__main__":
    main()

Adımlar

Zendesk Explore'a Erişin: Zendesk Support örneğinize, Zendesk Explore'da rapor oluşturma ve yönetme izinlerine sahip bir kullanıcı hesabıyla giriş yapın.
Yeni Bir Rapor Oluşturun: Explore modülüne gidin. Sol gezinme çubuğundaki 'Raporlar' simgesine tıklayın, ardından 'Yeni rapor' düğmesine tıklayın.
Veri Kümesini Seçin: 'Veri kümesi seçin' penceresinde, Support: Ticket updates [default] veri kümesini seçin. Bu veri kümesi, bir olay günlüğü oluşturmak için gerekli olan her bilet değişikliğinin denetim geçmişini içerir.
Başlangıç Niteliklerini (Sütunlar) Ekleyin: Rapor oluşturucuda, 'Satırlar' bölümüne gidin. 'Ekle'ye tıklayın ve aşağıdaki nitelikleri seçin. Bunlar olay günlüğünüzün sütunlarını oluşturacaktır: Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value, Comment public.
Hesaplanmış Nitelikler Oluşturun: Bu en kritik adımdır. 'Hesaplamalar' menüsüne (beher simgesi) gidin ve 'Standart hesaplanmış nitelik' seçeneğini belirleyin. Aşağıdaki 'Sorgu' bölümünde tanımlanan üç niteliği oluşturun: ActivityName, SourceSystem ve LastDataUpdate. Sağlanan formülleri tam olarak kopyalamanız gerekecektir.
Rapor Sütunlarını İyileştirin: Yeni oluşturduğunuz hesaplanmış nitelikleri (ActivityName, SourceSystem, LastDataUpdate) 'Satırlar' bölümüne ekleyin. Görünümü temizlemek için ActivityName'i oluşturmak için kullanılan ham alanları (Changes - Field name, Changes - Previous value, Changes - New value, Comment public) artık kaldırabilirsiniz.
Rapor Filtreleri Ekleyin: 'Filtreler' bölümüne gidin ve 'Ekle'ye tıklayın. 'Update - Date' için bir filtre ekleyin ve uygun bir tarih aralığı seçin (örn. son 3 ay). Hesaplanan niteliğiniz ActivityName üzerinde başka bir filtre ekleyin ve istenen bir etkinliğe karşılık gelmeyen bilet güncellemelerini kaldırmak için boş değerleri hariç tutun.
Raporu Çalıştırın ve İnceleyin: Zendesk Explore, nitelikler ve filtreler ekledikçe raporu otomatik olarak güncelleyecektir. Satırların ve sütunların beklendiği gibi göründüğünden emin olmak için veri tablosunu inceleyin. Rapor, olay başına bir satır göstermelidir.
Verileri CSV'ye Aktarın: Rapor tamamlandığında, sağ üst köşedeki 'Dışa Aktar' düğmesine tıklayın ve 'CSV'yi seçin. Zendesk, CSV dosyasını oluşturacak ve indirecektir.
Yükleme İçin Hazırlık: Dışa aktarılan CSV dosyasını açın. Sütun başlıklarını Process Mining aracınız için gerekli nitelik adlarıyla eşleşecek şekilde yeniden adlandırın (örn. 'Ticket ID'yi TicketId, 'Update - Timestamp'ı EventTimestamp olarak yeniden adlandırın). Zaman damgalarının tarih biçiminin ISO 8601 uyumlu olduğundan emin olun. Dosya artık yüklemeye hazırdır.

Konfigürasyon

Zendesk Veri Kümesi: Rapor, Support: Ticket updates [default] veri kümesi üzerine inşa edilmelidir. Bu, süreci olay bazında yeniden yapılandırmak için gereken ayrıntılı denetim geçmişini sağlayan tek standart veri kümesidir.
Tarih Aralığı Filtreleme: Veri hacmini sınırlamak için bir tarih filtresi uygulamak çok önemlidir. Birincil filtreniz olarak 'Update - Date' niteliğini kullanın. İlk analiz için genellikle 3-6 aylık veri aralığı önerilir.
Aktivite Filtresi: ActivityName hesaplanmış niteliğini oluşturduktan sonra, bu değerin boş olduğu satırları hariç tutmak için raporu filtrelemeniz gerekir. Bu, olay günlüğünüzdeki alakasız bilet değişikliklerini (örn. sistem güncellemeleri, etiket değişiklikleri) kaldırır.
Hesaplanmış Nitelikler: Bu çıkarımın mantığı, ham bilet alanı değişikliklerini insan tarafından okunabilir aktivite adlarına dönüştürmek için standart bir hesaplanmış niteliğe büyük ölçüde dayanır. Formüldeki hassasiyet çok önemlidir.
Ön Koşullar: Raporu çalıştıran kullanıcının Zendesk Explore'da en az 'Görüntüleyici' rolüne sahip olması gerekir. Raporu oluşturmak ve kaydetmek için 'Düzenleyici' veya 'Yönetici' izinleri gereklidir.

a Örnek Sorgu config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

Olay Yönetimi `Veri Template`'iniz

Olay Yönetimi `Veri Template`'iniz

Olay Yönetimi Nitelikleri

Olay Yönetimi Faaliyetleri

Veri Çekim Kılavuzları

Zendesk Explore UI Raporunu CSV Dosyasına Aktarma

Adımlar

Konfigürasyon

a Örnek Sorgu config

Zendesk Support REST API Kullanan Python Script'i

Adımlar

Konfigürasyon

a Örnek Sorgu python

Toplu Veri Senkronizasyonu için Zendesk Artımlı Dışa Aktarma API'si

Adımlar

Konfigürasyon

a Örnek Sorgu python

Zendesk API Bağlantılı Üçüncü Taraf ETL Aracı

Adımlar

Konfigürasyon

a Örnek Sorgu config

Başlamaya Hazır Mısınız?

Olay Yönetimini Optimize Edin, Daha Hızlı Çözüme Ulaşın

Olay Yönetimi Veri Template'iniz

Olay Yönetimi Veri Template'iniz

Olay Yönetimi Nitelikleri

Olay Yönetimi Faaliyetleri

Veri Çekim Kılavuzları

Zendesk Explore UI Raporunu CSV Dosyasına Aktarma

Adımlar

Konfigürasyon

a Örnek Sorgu config

Zendesk Support REST API Kullanan Python Script'i

Adımlar

Konfigürasyon

a Örnek Sorgu python

Toplu Veri Senkronizasyonu için Zendesk Artımlı Dışa Aktarma API'si

Adımlar

Konfigürasyon

a Örnek Sorgu python

Zendesk API Bağlantılı Üçüncü Taraf ETL Aracı

Adımlar

Konfigürasyon

a Örnek Sorgu config

Gizliliğinize önem veriyoruz

Başlamaya Hazır Mısınız?

Olay Yönetimini Optimize Edin, Daha Hızlı Çözüme Ulaşın

Olay Yönetimi `Veri Template`'iniz

Olay Yönetimi `Veri Template`'iniz