> Sürekli Süreç İyileştirme > Müşteri Enerji ve Altyapıi > Zendesk Destek > Veri Template'i

Müşteri Enerji ve Altyapıi `Data` Şablonunuz

Zendesk Destek

Müşteri Enerji ve Altyapıi Öznitelikleri (18) Müşteri Enerji ve Altyapıi Etkinlikleri (14) Veri Çıkarma Kılavuzları (4)

Müşteri Enerji ve Altyapıi `Data` Şablonunuz

Bu şablon, müşteri hizmetleri süreçlerinizi analiz etmek için doğru verileri toplamanıza yardımcı olur. Toplanması gereken temel veri öznitelikler.ini, izlenecek ana aktiviteleri özetler ve bu bilgileri nasıl çıkaracağınıza dair pratik rehberlik. eder. Bu kılavuzu kullanarak, stratejik bilgileri ortaya çıkarmak ve hizmet operasyonlarınızı iyileştirmek için güçlü bir olay logu oluşturabilirsiniz.

Önerilen Öznitelikler
Müşteri hizmetleri süreciniz için takip edilecek temel aktiviteler
Zendesk Support için veri veri çekme kılavuzu

Olay günlüklerine (Event Log) yeni mi başlıyorsunuz? Öğrenin Process Mining event log nasıl oluşturulur.

Template'i İndirin

Müşteri Enerji ve Altyapıi Öznitelikleri

Detaylı müşteri hizmetleri analizi için event lognuza dahil etmeniz önerilen veri alanları bunlardır.

5 Gerekli 6 Önerilen 7 Opsiyonel

	Ad	Açıklama
	Başlangıç Zamanı StartTime	Bir etkinlik veya olayın ne zaman başladığını gösteren zaman damgası (zaman damgası) (zaman damgası (zaman damgası)).
Açıklama Başlangıç Zamanı veya olay zaman damgası (zaman damgası), belirli bir faaliyetin meydana geldiği tam tarih ve saati kaydeder. Örneğin, bir müşteri yorumunun ne zaman eklendiğini, bir ajanın ne zaman atandığını veya talebin durumunun ne zaman 'Çözüldü' olarak değiştiğini yakalar. Bu zaman damgası (zaman damgası), olayların kronolojik sırasını belirlediği için Process Mining için büyük önem taşır. Aktiviteler arasındaki süreleri hesaplamak, döngü sürelerini ölçmek, SLA'lara karşı performansı analiz etmek ve hizmet sürecinin zamansal dinamiklerini anlamak için kullanılır. Neden Önemli?dir? Bu zaman damgası (zaman damgası), olayları sıralamak, süreleri hesaplamak ve hizmet talebi sürecinin zaman çizelgesini analiz etmek için gereklidir. Nereden Alınır?? Denetim izindeki her olay için Zendesk Ticket Audits API, `created_at` alanı. Örnekler::::::: 2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
	BT Hizmet Talebi Yönetimi ServiceRequest	Her müşteri hizmeti talebi için benzersiz tanımlayıcı, aynı zamanda talep veya vaka olarak da bilinir.
Açıklama BT Hizmet Talebi Yönetimi, tek bir müşteri sorgusu veya sorunuyla ilgili tüm aktiviteleri oluşturulmasından nihai çözümüne kadar bağlayan birincil vaka (case) tanımlayıcısıdır. Her etkileşim, güncelleme veya dahili eylem bu benzersiz kimliğe bağlıdır. Process Mining'de, BT Hizmet Talebi Yönetimine göre gruplandırılmış olayları analiz etmek, müşteri hizmetleri yolculuğunun uçtan uca eksiksiz bir görünümünü sunar. Toplam çözüm süresi gibi temel metrikleri hesaplamak, süreç sapmalarını belirlemek ve her müşteri sorununun süreç döngüsünü anlamak için temel oluşturur. Neden Önemli?dir? Bu, tüm süreç adımlarını birbirine bağlayan temel Case ID'dir ve her bir müşteri hizmetleri yolculuğunun yeniden yapılandırılmasını ve analizini sunar. Nereden Alınır?? Zendesk Tickets API, `id` alanı. Örnekler::::::: 102451287415332
	Aktivite Adı ActivityName	Hizmet talebi süreç döngüsü içinde meydana gelen belirli olayın veya görevin adı.
Açıklama Aktivite Adı, müşteri hizmetleri sürecindeki 'BT Hizmet Talebi Yönetimi Oluşturuldu', 'Talep Ajana Atandı' veya 'BT Hizmet Talebi Yönetimi Çözüldü' gibi tek bir adımı veya dönüm noktasını açıklar. Bu olaylar zaman damgalıdır ve her hizmet talebi için eylem dizisini oluşturur. Bu öznitelik, süreç akışını görselleştirmek, süreç varyantlarını keşfetmek ve olayların sıklığını ve sırasını analiz etmek için büyük önem taşır. Analistlerin hangi eylemlerin gerçekleştirildiğini anlamasına ve yaygın yolları, darboğazları ve standart prosedürden sapmaları belirlemesine sunar. Neden Önemli?dir? Bu öznitelik, süreç haritasının görselleştirilmesine ve süreç akışlarının ve varyasyonlarının analizine olanak tanıyan süreç adımlarını tanımlar. Nereden Alınır?? Zendesk bilet denetim günlüklerinden veya değişiklikleri ve eylemleri kaydeden olay akışlarından türetilmiştir. Örnekler::::::: Hizmet Talebi OluşturulduTalep Ajana AtandıTemsilcinin İlk Genel Yanıtı GönderildiBT Hizmet Talebi Yönetimi Çözüldü
	Kaynak Sistem SourceSystem	Verinin çıkarıldığı kayıt sistemi.
Açıklama Bu öznitelik, hizmet talebi verilerinin kaynak sistemini belirtir, bu durumda Zendesk Support'tur. Özellikle birden fazla sistemden veri birleştirilirken, veri yönetimi ve soy ağacı oluşturma konusunda yardımcı olur. Analizde, verilerin kaynağına doğru şekilde atfedilmesini sunar, bu da veri bütünlüğünü korumak ve sürecin bağlamını, özellikle çoklu sistem ortamlarında, anlamak için önemlidir. Neden Önemli?dir? Verinin kaynağını belirler, bu da veri yönetimi ve entegre ortamlardaki süreç verilerini ayırt etmek için büyük önem taşır. Nereden Alınır?? Bu, veri çıkarma işlemi sırasında verinin kaynağını etiketlemek için eklenen statik bir değerdir. Örnekler::::::: Zendesk Destek
	Son Veri Güncellemesi LastDataUpdate	Kaynak sistemden en son veri yenileme veya çekme işleminin zaman damgası (zaman damgası)dır.
Açıklama Bu öznitelik, veri setinin Zendesk Support'tan son güncellendiği zamanı gösterir. Analiz edilen verinin güncelliği hakkında bağlam sunar. Son güncelleme zamanını bilmek, analistler ve iş kullanıcıları için en güncel süreç bilgilerini görüp görmediklerini anlamaları açısından büyük önem taşır. Verinin yeniliği hakkındaki beklentileri yönetmeye yardımcı olur ve raporlama ve izleme amaçları için önemlidir. Neden Önemli?dir? Verinin güncelliği hakkında netlik sunar, kullanıcıların süreç analizinin ne kadar yeni olduğunu anlamasını garanti eder. Nereden Alınır?? Bu, veri çıkarma işlemi sırasında oluşturulan ve depolanan, çıkarma işinin zaman damgası (zaman damgası)nı kaydeden bir meta veri alanıdır. Örnekler::::::: 2023-10-27T02:00:00Z
	Atanan Temsilci AssignedAgent	Hizmet talebini ele almak üzere atanmış müşteri hizmetleri ajanının adı veya kimliği.
Açıklama Bu öznitelik, belirli bir zamanda bir aktiviteden veya hizmet talebinden sorumlu ajanı tanımlar. Talep yeniden atanırsa süreç döngüsü boyunca değişebilir. Atanan Ajana göre analiz yapmak, ajan iş yükünü, performansını ve verimliliğini anlamanın anahtarıdır. Farklı ajanlar arasında işlem süreleri ve vaka hacimlerinin karşılaştırılmasına izin vererek 'Ajan İş Yükü ve Verimliliği' kontrol paneli'unu destekler, koçluk fırsatlarını belirlemeye ve dengeli iş yüklerini güçlüaya yardımcı olur. Neden Önemli?dir? Hangi ajanın bir eylemi gerçekleştirdiğini izler; bireysel performansın, iş yükü dağıtımının ve kaynak tahsisinin analizini sunar. Nereden Alınır?? Zendesk Tickets API, `assignee_id` alanı. Kullanıcı detayları Users API'sinden alınabilir. Örnekler::::::: Can DemirAyşe YılmazDestekBotu
	BT Hizmet Talebi Yönetimi Türü ServiceRequestType	Hizmet talebinin 'Soru', 'Olay', 'Problem' veya 'Görev' gibi sınıflandırması.
Açıklama Bu öznitelik, hizmet talebini niteliğine göre kategorize eder. Bu sınıflandırma genellikle talep oluşturulduğunda veya tasnif edildiğinde ayarlanır ve uygun iş akışını ve önceliği belirlemeye yardımcı olur. Analizde, BT Hizmet Talebi Yönetimi Türüne göre segmentlere ayırmak temel teşkil eder. Bu, 'BT Hizmet Talebi Yönetimi Çözüm Süresi Analizi' ve 'Dahili Eskalasyon Oranı ve Nedenleri' gibi kontrol paneli'larda gösterildiği gibi, farklı sorun türleri için çözüm sürelerini, eskalasyon oranlarını ve süreç akışlarını karşılaştırmaya sunar. Bu, belirli talep türlerinin ele alınmasının daha sorunlu veya verimsiz olup olmadığını belirlemeye yardımcı olur. Neden Önemli?dir? Farklı türdeki sorunlar arasında performans karşılaştırması ve analizine olanak güçlüak için talepleri kategorize eder, bu da hedeflenen süreç iyileştirmesi için büyük önem taşır. Nereden Alınır?? Zendesk Tickets API, `type` alanı. Örnekler::::::: SoruOlayProblemGörev
	İletişim Kanalı CommunicationChannel	Hizmet talebinin gönderildiği veya iletişimin gerçekleştiği kanal.
Açıklama Bu öznitelik, e-posta, web formu, sohbet veya telefon gibi kullanılan iletişim yöntemini tanımlar. Müşterilerin hizmet masasıyla nasıl etkileşim kurduğunu yansıtır. Kanal kullanımını anlamak, kaynak planlaması ve müşteri deneyimini iyileştirmek için önemlidir. 'İletişim Kanalı Kullanımına Genel Bakış' kontrol paneli'u bu veriyi analiz ederek hangi kanalların en popüler olduğunu ve belirli kanalların daha uzun çözüm süreleri veya farklı süreç yolları ile ilişkili olup olmadığını gösterir. Bu, hizmet iyileştirmelerine veya otomasyona nerede yatırım yapılacağına karar vermede yardımcı olabilir. Neden Önemli?dir? Müşterilerin ve ajanların nasıl etkileşim kurduğunu göstererek, kanal verimliliğinin ve bunun süreç ile müşteri deneyimi üzerindeki etkisinin analizini sunar. Nereden Alınır?? Zendesk Tickets API, `via.channel` alanı. Örnekler::::::: webe-postaapisohbet
	Öncelik Priority	Hizmet talebine atanan öncelik düzeyi, örneğin 'Düşük', 'Normal', 'Yüksek' veya 'Acil'.
Açıklama Öncelik, bir hizmet talebinin aciliyetini gösterir ve genellikle kuyruktaki konumunu ve hedef çözüm süresini etkiler. Ajanların önce en kritik konulara odaklanmasına yardımcı olur. Bu öznitelik, performans ve SLA analizi için büyük önem taşır. 'BT Hizmet Talebi Yönetimi Çözüm Süresi Analizi' kontrol paneli'u, veriyi önceliğe göre segmentlere ayırarak, yüksek öncelikli taleplerin düşük öncelikli olanlardan daha hızlı ele alınıp alınmadığını ve kaynakların iş ihtiyaçlarına göre etkin bir şekilde tahsis edilip edilmediğini ortaya koyar. Neden Önemli?dir? Bir talebin aciliyetini gösterir; bu, SLA uyumluluğunu analiz etmek ve kritik sorunların zamanında ele alınmasını güçlüak için büyük önem taşır. Nereden Alınır?? Zendesk Tickets API, `priority` alanı. Örnekler::::::: DüşükNormalYüksekAcil
	SLA Hedef Çözüm Süresi SlaTargetResolutionTime	Bir hizmet talebinin SLA politikasına göre çözülmesi beklenen hedef süre.
Açıklama Bu öznitelik, bir talebi çözmek için Hizmet Seviyesi Anlaşması (SLA) hedefini tanımlar. Bu hedef genellikle dinamiktir ve talebin önceliği, türü veya müşterinin hizmet planı gibi faktörlere bağlıdır. Bu, 'SLA Uyumluluk Performansı' kontrol paneli'u için temel bir özniteliktir. Gerçek çözüm süresinin ölçüldüğü bir karşılaştırma noktası olarak olarak kullanılır. Bu hedefe karşı performansı analiz etmek, hizmet sunum kalitesini niceliksel olarak belirlemeye ve müşterilere karşı sözleşme yükümlülüklerinin yerine getirildiğinden emin olmaya yardımcı olur. Neden Önemli?dir? Müşteriye verilen hizmet taahhüdünü tanımlar, zamanında performans ve SLA uyumluluğunu ölçmek için bir referans noktası görevi görür. Nereden Alınır?? Bir bilete uygulanan SLA politikalarından türetilmiştir. Bu bilgi, Zendesk Bilet Metrikleri API'si aracılığıyla edinilebilir. Örnekler::::::: 144002880086400
	SLA İhlal Edildi mi? IsSlaBreached	Hizmet talebinin çözüm süresinin SLA hedefini aşıp aşmadığını gösteren bir boolean değeri.
Açıklama Bu hesaplanmış öznitelik, bir hizmet talebinin çözüm süresi için tanımlanmış Hizmet Seviyesi Anlaşmasını karşılayıp karşılamadığını gösteren basit bir doğru veya yanlış bayrağıdır. Gerçek çözüm süresinin planlanan SLA hedefiyle karşılaştırılmasıyla elde edilir. Bu bayrak, SLA uyumluluk analizini basitleştirir. 'SLA Uyumluluk Performansı' kontrol paneli'u ve 'SLA Uyumluluk Oranı' KPI'ı için temel veri noktasıdır ve kaç talebin hizmet hedeflerini karşıladığını ve kaçının karşılamadığını hızlı bir şekilde birleştirmeyi ve görselleştirmeyi sunar. Neden Önemli?dir? Her vaka için SLA performansına dair net, ikili bir sonuç sunarak uyumluluk izlemeyi ve raporlamayı basitleştirir. Nereden Alınır?? Veri dönüşümü sırasında toplam çözüm süresinin SlaTargetResolutionTime ile karşılaştırılmasıyla hesaplanır. Örnekler::::::: truefalse
	Bilgi Talebi Sayısı InformationRequestCount	Tek bir hizmet talebi için müşteriden bilgi talep edilme sayısı.
Açıklama Bu hesaplanmış metrik, her hizmet talebi için 'Müşteriden Bilgi Talep Edildi' aktivitesinin gerçekleşme sayısını sayar. Yüksek bir sayı, ajanların gerekli tüm bilgileri başlangıçta toplamadığını gösterir. Bu öznitelik, 'Tekrarlanan Bilgi Talebi Analizi' kontrol paneli'unda kullanılır. Bu sayıyı izlemek, süreç verimsizliklerini ve ajan eğitimi için alanları belirlemeye yardımcı olur. Bilgi talep edilme sayısını azaltmak, çözüm sürelerini önemli ölçüde kısaltabilir ve müşteri deneyimini iyileştirebilir. Neden Önemli?dir? Müşteri ile karşılıklı iletişimi niceliksel olarak belirler; bu da çözüm sürelerini uzatan ve müşteri deneyimini kötüleştiren verimsizlikleri vurgular. Nereden Alınır?? Her BT Hizmet Talebi Yönetimi için (ActivityName)'in 'Müşteriden Bilgi Talep Edildi' olduğu olayların sayısını sayarak hesaplanır. Örnekler::::::: 013
	Bitiş Zamanı EndTime	Bir aktivitenin veya olayın ne zaman tamamlandığını gösteren zaman damgası (zaman damgası)dır.
Açıklama Bitiş Zamanı, bir aktivitenin tamamlanma süresini temsil eder. Birçok olay logu yapısında, bir sonraki aktivitenin Başlangıç Zamanı, mevcut aktivitenin Bitiş Zamanı olarak işlev görebilir. 'Ajan Sorunu Araştırır' gibi duruma dayalı aktiviteler için, o durumun ne zaman sona erdiğini işaret eder. Bu öznitelik, performans analizinin temel bir bileşeni olan aktivitelerin kesin süresini hesaplamak için gereklidir. Hangi adımların en çok zaman aldığını belirlemeye yardımcı olur ve detaylı darboğaz analizi ile kaynak verimliliği hesaplamaları için temel sunar. Neden Önemli?dir? Aktivite sürelerinin hesaplanmasını sunar, bu da darboğazları belirlemek ve performansı ölçmek için büyük önem taşır. Nereden Alınır?? Bu, genellikle belirli bir BT Hizmet Talebi Yönetimi için dizideki sonraki olayın Başlangıç Zamanı alınarak türetilir. Örnekler::::::: 2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
	Çözüm Kodu ResolutionCode	Talebin nihai çözümü veya kapanma nedenini gösteren bir kod veya kategori.
Açıklama Çözüm Kodu, bir hizmet talebinin sonucu hakkında yapılandırılmış bilgi sunar. Örnekler::::::: arasında 'Ajan Tarafından Çözüldü', 'Tekrar Eden', 'Eylem Gereksiz' veya 'Bilinen Sorun' bulunur. Basit bir 'Kapalı' durumundan daha fazla bağlam sunar. Bu öznitelik, kök neden analizi için özellikle değerlidir. 'Yeniden Açılan BT Hizmet Talebi Yönetimi Trendleri' kontrol paneli'u için, çözüm koduna göre yeniden açılma oranlarını analiz etmek, belirli çözüm türlerinin daha az etkili olup olmadığını ortaya çıkarabilir ve bu da müşterilerin destekle yeniden etkileşime geçmesine neden olabilir. Neden Önemli?dir? Bir hizmet talebinin sonucu hakkında bilgi sunar, bu da kök neden analizi ve taleplerin neden yeniden açıldığını anlamak için büyük önem taşır. Nereden Alınır?? Bu genellikle Zendesk'te özel bir talep alanıdır. Kesin alan adı, belirli Zendesk yapılandırmasına bağlıdır. Örnekler::::::: İlk Temasta Çözüm2. Seviyeye YükseltildiMüşteri BekleniyorÜrün Hatası
	Memnuniyet Puanı SatisfactionRating	Hizmet talebi çözüldükten sonra müşteri tarafından verilen memnuniyet puanı.
Açıklama Bu öznitelik, müşterinin hizmet deneyimine ilişkin geri bildirimlerini yakalar; bu, genellikle talep çözüldükten sonra bir anket aracılığıyla toplanır. Yaygın derecelendirmeler arasında 'İyi', 'Kötü' veya sayısal bir puan bulunur. Bu, müşteri duyarlılığının doğrudan bir ölçüsüdür ve temel bir sonuç metriğidir. 'Müşteri Duyarlılığı Puanı' KPI'ını hesaplamak için kullanılır. Memnuniyet derecelendirmelerini, çözüm süresi veya ajan etkileşim sayısı gibi süreç verileriyle birlikte analiz etmek, hangi süreç davranışlarının daha iyi müşteri sonuçlarına yol açtığını ortaya çıkarabilir. Neden Önemli?dir? Sağlanan hizmete ilişkin doğrudan müşteri geri bildirimini ölçer, süreç performansını müşteri sonuçlarıyla ilişkilendirir. Nereden Alınır?? Zendesk Tickets API, `satisfaction_rating.score` alanı. Örnekler::::::: goodbadoffered
	Temsilci Grubu AgentGroup	Hizmet talebinin atandığı destek grubu veya ekip.
Açıklama Bu öznitelik, hizmet talebinden sorumlu ajan ekibini temsil eder. Talepler genellikle beceriye, ürün alanına veya dile göre belirli gruplara yönlendirilir. Ajan Grubuna göre analiz yapmak, ekip düzeyinde performansı, iş yükü dağılımını ve ekipler arası eskalasyon modellerini anlamaya yardımcı olur. Bireysel ajan analizinden daha üst düzey bir görünüm sunar ve belirli departmanlar veya fonksiyonlar içindeki sistemik sorunları belirlemeye yardımcı olabilir. Neden Önemli?dir? Ekip sorumluluğunu izler; grup performansının, ekipler arası devirlerin ve farklı destek katmanları veya uzmanlık alanları genelinde kaynak tahsisinin analizini sunar. Nereden Alınır?? Zendesk Tickets API, `group_id` alanı. Grup detayları Groups API'sinden alınabilir. Örnekler::::::: 1. Kademe DestekTeknik DestekFaturalandırma
	Ürün Hizmet Kategorisi ProductServiceCategory	Müşterinin talebinin ilgili olduğu belirli ürün, hizmet veya özellik.
Açıklama Bu öznitelik, hizmet talebini bir ürün veya hizmet alanına göre kategorize ederek detaylı bağlam sunar. Genellikle bir ajan tarafından manuel olarak veya talep içeriğine göre otomatik olarak ayarlanır. Bu kategorizasyon, 'Talep Kategorizasyon Doğruluğu' ve 'Araştırma Döngüsü Süresi Dağılımı' panelleri için büyük önem taşır. Hangi ürünlerin en çok destek talebi oluşturduğunu, hangilerinin çözülmesi en karmaşık olduğunu ve ilk kategorizasyonun nihai çözümle uyumlu olup olmadığını derinlemesine analiz etmeye sunar, bu da yönlendirme ve ajan eğitimini iyileştirmeye yardımcı olur. Neden Önemli?dir? Talepleri belirli iş alanlarına, ürünlere veya hizmetlere bağlar, böylece sorunlu alanlar ve bunların süreç üzerindeki etkileri üzerine odaklanmış analizlere sunar. Nereden Alınır?? Bu genellikle Zendesk'te özel bir talep alanıdır. Kesin alan adı, belirli Zendesk yapılandırmasına bağlıdır. Örnekler::::::: Mobil UygulamaAbonelik YönetimiAPI EntegrasyonuDonanım
	Yeniden Açıldı mı? IsReopened	Bir hizmet talebinin çözüldü olarak işaretlendikten sonra yeniden açılıp açılmadığını gösteren bir boolean değeri.
Açıklama Bu öznitelik, bir hizmet talebinin daha önce çözüldü veya kapatıldı olarak ayarlandıktan sonra açık duruma geri dönmesi durumunda doğru olan bir bayraktır. İlk çözümün yeterli olmadığını gösterir. Bu bayrak, yeniden işleme ve ilk temasta çözüm başarısızlıklarını izlemek için büyük önem taşır. Ek dikkat gerektiren vakaları kolayca saymayı ve analiz etmeyi sağlayarak 'Yeniden Açılan BT Hizmet Talebi Yönetimi Trendleri' kontrol paneli'unu ve 'BT Hizmet Talebi Yönetimi Yeniden Açılma Oranı' KPI'ını doğrudan destekler; bu da genellikle daha derin temel sorunları gösterir. Neden Önemli?dir? Yeniden işleme ve başarısız çözümleri belirler, sağlanan çözümlerin kalitesini ve etkinliğini ölçmeye yardımcı olur. Nereden Alınır?? Veri dönüşümü sırasında, bir biletin durumunun 'çözüldü' veya 'kapalı'dan tekrar 'açık'a değişip değişmediği kontrol edilerek hesaplanır. Örnekler::::::: truefalse

Gerekli Önerilen Opsiyonel

Müşteri Enerji ve Altyapıi Etkinlikleri

Bunlar, doğru müşteri hizmetleri süreç keşfi için olay logunuzda yakalamanız gereken temel süreç adımları ve dönüm noktaları.dır.

6 Önerilen 8 Opsiyonel

	Aktivite	Açıklama
	BT Hizmet Talebi Yönetimi Çözüldü	Bir temsilci, müşteriye bir çözüm sunduktan sonra hizmet talebini 'çözüldü' olarak işaretler. Bu geçici bir durumdur, çünkü bilet kalıcı olarak kapatılmadan önce bir müşteri yanıtıyla yeniden açılabilir.
Neden Önemli?dir? Bu, çözüm süresini ve ajan verimliliğini ölçmek için birincil dönüm noktasıdır. Ajana göre işin tamamlandığı noktayı işaret eder ve talep yeniden açılırsa yeniden işleme analizleri için bir temel sunar. Nereden Alınır?? Bu, Zendesk Ticket Audits API'sinde 'status' alanı 'çözüldü' olarak ayarlandığında kaydedilen açık bir durum değişikliğidir. Yakala Bilet durumunun 'çözüldü' olarak ayarlandığı Bilet Denetimlerindeki 'Değişiklik' olaylarını belirleyin. Event tipi explicit
	BT Hizmet Talebi Yönetimi Kapatıldı	Bu, hizmet talebinin kalıcı olarak kapanışını işaret eden son aktivitedir. Genellikle talep 'çözüldü' olarak işaretlendikten sonra belirli bir süre geçtikten sonra, müşteriden yeni yanıt gelmeksizin otomatik olarak gerçekleşir.
Neden Önemli?dir? Kesin son olay olarak, biletin süreç döngüsünü tamamlar. 'Çözüldü'den 'kapalı'ya kadar geçen süre, olası yeniden açılmalar için bir pencereyi temsil eder ve 'kapalı' olayı, çözümün kabul edildiğini doğrular. Nereden Alınır?? Bu, Zendesk Ticket Audits API'sinde 'status' alanı 'kapalı' olarak ayarlandığında kaydedilen açık bir durum değişikliğidir. Yakala Bilet durumunun 'kapalı' olarak ayarlandığı Bilet Denetimlerindeki 'Değişiklik' olaylarını belirleyin. Event tipi explicit
	BT Hizmet Talebi Yönetimi Yeniden Açıldı	Bu aktivite, bir müşteri 'çözüldü' durumundaki bir talebe yanıt verirse meydana gelir. Zendesk, sorunun tam olarak çözülmediğini göstererek durumu otomatik olarak 'açık' konumuna geri değiştirir.
Neden Önemli?dir? Yeniden açılmalar, İlk Temasta Çözüm başarısızlığının ve düşük çözüm kalitesinin kritik bir göstergesidir. Yeniden açılan taleplerin sıklığını ve nedenlerini analiz etmek, ajan eğitimini ve çözüm prosedürlerini iyileştirme alanlarını belirlemeye yardımcı olur. Nereden Alınır?? Bu, Ticket Audits API'sinde 'status' 'çözüldü'den tekrar 'açık' konumuna geçtiğinde yakalanan açık bir durum değişikliğidir. Yakala Durum 'Değişiklik' olaylarını 'çözüldü'den 'açık'a izleyin. Event tipi explicit
	Hizmet Talebi Oluşturuldu	Bu aktivite, müşteri hizmetleri sürecinin başlangıcını işaret eder; Zendesk'te e-posta, web formu veya sohbet gibi herhangi bir kanaldan yeni bir talep oluşturulduğunda. Bu olay, sistem tarafından benzersiz bir talep kimliği ve oluşturma zaman damgası (zaman damgası) ile açıkça kaydedilir.
Neden Önemli?dir? Birincil başlangıç olayı olarak, genel vaka süresini hesaplamak ve zaman içindeki gelen talep hacimlerini analiz etmek için gereklidir. İlk yanıt süresi ve toplam çözüm süresi gibi temel performans göstergelerini ölçmek için bir temel görevi görür. Nereden Alınır?? Bu, Zendesk Ticket Audits API'sinde yakalanan açık bir olaydır. Bir talep için 'Oluştur' olayına karşılık gelir ve ilk oluşturma zaman damgası (zaman damgası)nı sunar. Yakala Bilet Denetimleri günlüğündeki bilet oluşturma olayından yakalanır. Event tipi explicit
	Müşteriden Bilgi Talep Edildi	Bir temsilcinin devam etmek için müşteriden daha fazla bilgiye ihtiyaç duyduğunda ve bilet durumunu 'beklemede' olarak değiştirdiğinde gerçekleşir. Bu durum değişikliği, sürecin artık harici bir tarafı beklediğini açıkça belirtir.
Neden Önemli?dir? Bu aktivite, müşteriye bağımlılıkları vurgular ve dahili SLA sürelerini duraklatır. Tek bir talepte sık veya tekrarlanan örnekler, eksik başlangıç bilgi toplama işaret edebilir ve daha uzun çözüm sürelerine yol açabilir. Nereden Alınır?? Bu, Zendesk Ticket Audits API'sinde kaydedilen açık bir durum değişikliği olayıdır. 'status' alanı 'pending' olarak değiştiğinde yakalanır. Yakala Bilet durumunun 'beklemede' olarak ayarlandığı Bilet Denetimlerindeki 'Değişiklik' olaylarını belirleyin. Event tipi explicit
	Talep Ajana Atandı	Bu olay, hizmet talebinin belirli bir ajana atanmış olduğunu gösterir. Yönlendirme kurallarına göre otomatik olarak veya bir ekip lideri veya ajan tarafından manuel olarak gerçekleşebilir.
Neden Önemli?dir? Atama, hesap verebilirlik ve iş yükü yönetimi için kritik bir dönüm noktasıdır. Atama süresini ve yeniden atama kalıplarını analiz etmek, triyaj ve dağıtım sürecindeki darboğazları ortaya çıkarır. Nereden Alınır?? Bu, Zendesk Ticket Audits API'sinde 'assignee_id' alanı doldurulduğunda veya değiştirildiğinde kaydedilen açık bir 'Değişim' olayıdır. Yakala Ticket Audits logundaki 'assignee_id' alanındaki değişiklikleri izleyin. Event tipi explicit
	Dahili Eskalasyon Tetiklendi	Bir hizmet talebinin farklı bir dahili ekibe veya daha yüksek bir destek katmanına aktarılmasını temsil eder. Bu genellikle talebin atanan grubu değiştiğinde anlaşılır.
Neden Önemli?dir? Eskalasyonları izlemek, süreç zayıflıklarını, ön cephe desteğindeki bilgi eksikliklerini ve karmaşık talep türlerini belirlemek için temel rol oynar. Yüksek eskalasyon oranları, daha iyi eğitim veya süreç dokümantasyonu ihtiyacını gösterebilir. Nereden Alınır?? 'group_id' alanının değiştirildiği Bilet Denetimleri API'sindeki bir 'Değişiklik' olayından çıkarılır. Bir gruptaki değişiklik, ekipler arasında bir aktarım anlamına gelir. Yakala Bilet Denetim günlüğündeki 'group_id' alanındaki değişiklikleri izleyin. Event tipi inferred
	İlk Onay Gönderildi	Müşteriye gönderilen, talebinin alındığını onaylayan otomatik ilk yanıtı temsil eder. Bu genellikle talep oluşturulduktan hemen sonra şablonlu bir e-posta bildirimi gönderen bir Zendesk tetikleyicisi tarafından yapılır.
Neden Önemli?dir? Bu aktiviteyi izlemek, ilk yanıt hızını ölçmek ve müşteri beklentilerini yönetmek için büyük önem taşır. Talep oluşturma ile bu onay arasındaki süre, müşteri memnuniyeti için temel bir göstergedir. Nereden Alınır?? Bilet üzerindeki ilk genel yorumun yazarı otomatik bir kullanıcıysa veya bilet oluşturulduktan saniyeler içinde gerçekleşmişse bu yorumdan çıkarılır. Bu, Bilet Yorumları akışı analiz edilerek belirlenebilir. Yakala Bilet oluşturulduktan hemen sonra bir otomasyon veya tetikleyici tarafından oluşturulan ilk genel yorumu belirleyin. Event tipi inferred
	Memnuniyet Anketi Gönderildi	Müşteri memnuniyeti (CSAT) anketinin müşteriye otomatik olarak gönderildiği noktayı temsil eder. Bu genellikle talep çözüldü olarak işaretlendikten kısa bir süre sonra gerçekleşir.
Neden Önemli?dir? Bu aktivite, müşteri geri bildirim döngüsünü başlatır. Anketlerin ne zaman ve gönderilip gönderilmediğini anlamak, memnuniyet puanlarını bağlamsallaştırmak ve geri bildirim programının etkinliğini ölçmek için önemlidir. Nereden Alınır?? Bu, bir otomasyon logundan veya talebe eklenen belirli bir etiketle çıkarılabilir. Ticket Audits API'sindeki 'satisfaction_rating' bölümü de anketin ne zaman sunulduğunu kaydeder. Yakala 'csat_sent' gibi etiketleri arayın veya memnuniyet derecelendirmesinin sunulduğu zaman damgası (zaman damgası)nı kullanın. Event tipi inferred
	Memnuniyet Derecesi Alındı	Bu olay, müşterinin memnuniyet anketine yanıtını gönderdiğinde meydana gelir ve 'İyi' veya 'Kötü' gibi bir derecelendirme sunar. Derecelendirme ve ilgili yorum talebe karşı kaydedilir.
Neden Önemli?dir? Doğrudan müşteri geri bildirimi, hizmet kalitesini ve müşteri duyarlılığını ölçmek için büyük önem taşır. Bu derecelendirmeleri süreç akışı bağlamında analiz etmek, belirli aktiviteleri veya temsilcileri sonuçlarla ilişkilendirmeye yardımcı olur. Nereden Alınır?? Müşterinin puanı ve yorumuyla 'satisfaction_rating' alanı doldurulduğunda, Bilet Denetimleri API'sinde bir 'Değişiklik' olayı olarak yakalanır. Yakala 'satisfaction_rating' alanındaki değişiklikler için Bilet Denetim günlüklerini filtreleyin. Event tipi explicit
	Müşteri Yanıtladı	Bu olay, bir müşterinin, genellikle 'beklemede' durumunda olan bir talebe yanıt vermesiyle tetiklenir. Zendesk, ajanın işine devam edebileceğini işaret ederek talep durumunu otomatik olarak 'beklemede' konumundan 'açık' konumuna geri geçirir.
Neden Önemli?dir? Bu aktivite, bir bekleme süresinin sonunu işaret eder ve sürecin devam etmesi için bir tetikleyicidir. Müşterilerin yanıt vermek için harcadıkları süreyi analiz etmek, ajan taleplerinin netliği hakkında stratejik bilgiler sağlayabilir. Nereden Alınır?? Bu olay, son kullanıcıdan gelen yeni bir herkese açık yorumla ilişkilidir ve bu, Ticket Audits API'sinde durumun 'beklemede' konumundan 'açık' konumuna açık bir şekilde değişmesini tetikler. Yakala Durum 'Değişiklik' olaylarını 'beklemede'den 'açık'a izleyin veya bir son kullanıcıdan gelen yeni herkese açık yorumları belirleyin. Event tipi explicit
	SLA İhlali Meydana Geldi	Bu aktivite, bir hizmet talebinin ilk yanıt süresi veya çözüm süresi gibi önceden tanımlanmış bir Hizmet Seviyesi Anlaşmasını karşılayamadığı anı işaret eder. Bu olay, talep aktivitesi zaman damgalarının SLA politikalarına göre karşılaştırılmasıyla hesaplanır.
Neden Önemli?dir? SLA ihlalleri, müşteri memnuniyetini ve sözleşme uyumluluğunu doğrudan etkiler. Ne zaman ve neden meydana geldiklerini analiz etmek, sistemik gecikmeleri, kaynak kıtlıklarını veya gerçekçi olmayan performans hedeflerini belirlemek için büyük önem taşır. Nereden Alınır?? Bu, SLA ihlal zaman damgalarını ('breached_at') depolayan Zendesk Ticket Metrics API'sinden alınabilir. Alternatif olarak, talep olayı zaman damgaları tanımlı SLA kurallarına göre karşılaştırılarak hesaplanabilir. Yakala Ticket Metrics API'sinden 'breached_at' zaman damgası (zaman damgası)nı kullanın veya çözüm süresini SLA politika süresiyle karşılaştırarak hesaplayın. Event tipi calculated
	Talep Kategorize Edildi ve Önceliklendirildi	Bu aktivite, bir ajan veya otomasyon, tür, kategori ve öncelik gibi talep alanlarını ayarladığında veya güncellediğinde meydana gelir. Bu adım, talebin geçmişinde bir değişiklik olayı olarak kaydedilir.
Neden Önemli?dir? Doğru kategorizasyon ve önceliklendirme, etkin yönlendirme ve kaynak tahsisi için büyük önem taşır. Bu aktiviteyi analiz etmek, ilk tasnifin doğruluğunu ve çözüm süreleri üzerindeki etkisini belirlemeye yardımcı olur. Nereden Alınır?? Zendesk Bilet Denetimleri API'sinden 'Değişiklik' olayları olarak yakalanır. 'öncelik', 'tür' veya kategorizasyonla ilgili özel alanlara yapılan ilk güncellemeyi arayarak belirlenebilir. Yakala Oluşturulduktan sonra temel kategorizasyon alanlarındaki ilk 'Değişiklik' olayı için Bilet Denetim günlüklerini filtreleyin. Event tipi explicit
	Temsilcinin İlk Genel Yanıtı Gönderildi	Bu aktivite, bir ajanın müşteriye otomatik bir onay yerine ilk kez herkese açık bir yorum göndermesini işaret eder. Bu olay, ajanın müşterinin sorunuyla ilk etkileşiminin önemli bir göstergesidir.
Neden Önemli?dir? Bu, hizmet duyarlılığının kritik bir göstergesi olan 'İlk Yanıt Süresi' SLA'sını ölçmek için önemli bir dönüm noktasıdır. Otomatik iletişimi, aktif, insan odaklı araştırma ve desteğin başlangıcından ayırır. Nereden Alınır?? Yazarın insan bir temsilci (otomatik sistem kullanıcısı değil) olduğu Bilet Yorumları akışındaki ilk genel yorumu bularak belirlenir. Yakala Talep yorumlarını tarayın, ajanlardan gelen herkese açık yorumları filtreleyin ve en erken zaman damgalı olanı seçin. Event tipi inferred

Önerilen Opsiyonel

Veri Çıkarma Kılavuzları

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

Adımlar

Zendesk Explore'a Gidin: Zendesk hesabınıza giriş yapın, üst çubuktaki ürün başlatıcı simgesine tıklayın ve Explore'u seçerek ürünü açın.
Yeni Bir Sorgu Oluşturun: Explore içinde sol kenar çubuğundaki Sorgular simgesine, ardından sağ üstteki "New query" düğmesine tıklayın.
Dataset Seçin: "Choose a dataset" penceresinde Support: Tickets dataset seçeneğini belirleyin. Bu dataset, temel ticket niteliklerini ve ana event zaman damgası (zaman damgası) değerlerini içerir.
Metrik Ekleyin: Sorgu oluşturucuda "Metrics" paneline giderek "Add"e tıklayın. COUNT(Tickets) seçimini yapın. Bu, data hacmini doğrulamanıza yardımcı olur.
Satırlara Öznitelikler Ekleyin: "Rows" paneline gidin ve "Add"e tıklayın. Geniş formatlı dışa aktarma dosyanızın temel sütunlarını oluşturacak şu nitelikleri ekleyin:
- Ticket ID (Bu sizin case tanımlayıcı değerinizdir, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestType)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Satırlara Aktivite zaman damgası (zaman damgası) Değerlerini Ekleyin: "Rows" paneline aşağıdaki zaman damgası (zaman damgası) niteliklerini ekleyin. Bunların her biri potansiyel bir aktiviteyi temsil eder. Bazı aktiviteler için özel hesaplanmış bir öznitelik oluşturmanız gerekebilir.
- Ticket created - zaman damgası (zaman damgası): Service Request Created ve Initial Acknowledgment Sent için.
- Ticket assigned - zaman damgası (zaman damgası): Request Assigned To Agent için.
- First reply time - zaman damgası (zaman damgası): First Agent Public Reply Sent için.
- Ticket solved - zaman damgası (zaman damgası): Service Request Resolved ve Satisfaction Survey Sent için.
- Ticket reopened - zaman damgası (zaman damgası): Service Request Reopened için.
- Satisfaction rating received - zaman damgası (zaman damgası): Satisfaction Rating Received için.
- Ticket closed - zaman damgası (zaman damgası): Service Request Closed için.
Diğer Aktiviteler İçin Özel Hesaplanmış Öznitelikler Oluşturun: Bazı aktiviteler belirli alan değişikliklerine dayalıdır ve zaman damgası (zaman damgası) değerlerini yakalamak için özel öznitelik oluşturulmasını gerektirir. Hesaplamalar menüsüne (hesap makinesi simgesi) gidin ve "Standard calculated nitelik" seçeneğini belirleyin. Aşağıdaki her bir aktivite için bir öznitelik oluşturun (Zendesk örneğinizdeki alan ve değerlerin tam adlarını kullanmanız gerekecektir):
- Ad: zaman damgası (zaman damgası) - Categorized and Prioritized. Formül: IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - zaman damgası (zaman damgası)] ENDIF. Oluşturduktan sonra bu yeni özniteliği "Rows" paneline ekleyin ve aggregator değerini MIN olarak değiştirin.
- Ad: zaman damgası (zaman damgası) - Info Requested. Formül: IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - zaman damgası (zaman damgası)] ENDIF. "Rows" paneline ekleyin ve aggregator'ı MIN yapın.
- Ad: zaman damgası (zaman damgası) - Customer Responded. Formül: IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - zaman damgası (zaman damgası)] ENDIF. "Rows" paneline ekleyin ve aggregator'ı MIN yapın.
- Ad: zaman damgası (zaman damgası) - Escalated. Formül: IF ([Changes - Field name] = "group") THEN [Update - zaman damgası (zaman damgası)] ENDIF. "Rows" paneline ekleyin ve aggregator'ı MIN yapın.
- Ad: zaman damgası (zaman damgası) - SLA Breach. Formül: IF ([SLA breach status]=TRUE) THEN [SLA update - zaman damgası (zaman damgası)] ENDIF. "Rows" paneline ekleyin ve aggregator'ı MIN yapın.
Data Filtreleme: "Filters" paneline gidip "Add"e tıklayın. Ticket created - Date için bir filtre ekleyin ve dataset'i yönetilebilir tutmak için son 3-6 ay gibi uygun bir tarih aralığı seçin.
Raporu Çalışanştırın ve Dışa Aktarın: Sorguyu kaydetmek için "Save"e tıklayın. Tablo verileri gösterdiğinde "Export" düğmesine tıklayarak CSV veya Excel gibi tercih ettiğiniz formatı seçin.
Data'yı Event Log Formatına Dönüştürün: Dışa aktarılan dosya, her satırın bir ticket ve her sütunun bir event zaman damgası (zaman damgası) olduğu "wide" formatındadır. Process Mining için bunu "long" formata dönüştürmeniz gerekir. Bunun için Microsoft Excel (Power Query'deki Unpivot özelliğiyle), Python veya benzeri bir data hazırlama aracı kullanın.
- Her satır (ticket) için, boş olmayan her zaman damgası (zaman damgası) sütununa karşılık gelecek şekilde birden fazla yeni satır oluşturun.
- Nihai tabloda ServiceRequest, (ActivityName), StartTime gibi sütunlar bulunmalı ve diğer öznitelikler. her bir service request aktivitesi için yinelenmelidir.

Konfigürasyon

Veri Kümesi: Kullanılacak birincil veri kümesi Support: Tickets'tır. Bu, tek bir sorguda çoğu bilet özelliğine ve temel zaman damgalarına erişim sunar.
İzinler: Sorgu oluşturmak ve kaydetmek için Zendesk Explore'da en az Editör veya Yönetici rolüne sahip olmanız gerekir.
Tarih Aralığı: Ticket created - Date alanına bir tarih aralığı filtresi ayarlamak büyük önem taşır. Performans ile önemli bilgiyü dengelemek için 3 ila 6 aylık bir veri aralığı önerilir. Milyonlarca bileti dışa aktarmak yavaş olabilir veya başarısız olabilir.
Sorgu Filtreleri: Analizi belirli bir hizmete veya ekibe odaklamak için Ticket brand, Ticket form veya Ticket group gibi belirli bilet özelliklerine filtreler eklemeyi düşünebilirsiniz.
Hesaplanmış Öznitelikler: Bu yöntem, durum değişiklikleri veya eskalasyonlar gibi varsayılan nitelikler olmayan olaylar için zaman damgalarını yakalamak amacıyla standart hesaplanmış nitelikler oluşturmaya büyük ölçüde dayanır. Bu nitelikleri oluşturma izinlerine sahip olduğunuzdan emin olun.

a Örnek Sorgu config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Adımlar

Zendesk API Erişimini Hazırlayın: Zendesk'e yönetici olarak giriş yapın. Admin Center'a gidin, ardından Apps and integrations > APIs > Zendesk API yolunu izleyin. Settings sekmesi altında Token Access özelliğinin etkinleştirildiğinden emin olun. 'Add API token' butonuna tıklayarak yeni bir belirteç oluşturun. Belirteci bir daha görüntülenemeyeceği için güvenli bir yere kopyalayın.
Python Ortamını Kurun: Python 3.6 veya daha yeni bir sürümün yüklü olduğundan emin olun. Zendesk API'sine HTTP istekleri göndermek için gerekli olan requests kütüphanesini kurun. Komut satırına pip install requests yazarak yükleme yapabilirsiniz.
Python Betiğini Yapılandırın: Size sağlanan Python betiğini extract_zendesk_log.py gibi bir isimle kaydedin. Dosyayı bir metin düzenleyicide açarak üst kısımdaki yer tutucu değişkenleri (ZENDESK_SUBDOMAIN, ZENDESK_EMAIL ve API_TOKEN) kendi Zendesk bilgilerinizle güncelleyin.
Data Çekme Aralığını Belirleyin: Betik içindeki START_TIMESTAMP değişkenini bulun. Bu değer, data çekme işleminin başlangıç tarihini belirler. Bir Unix epoch zaman damgası (zaman damgası) formatında olmalıdır. İlk analiz için son 3-6 ayı kapsayan bir değer girmeniz önerilir.
Betiği Çalışanştırın: Terminali veya komut istemini açın, betiği kaydettiğiniz dizine gidin ve şu komutu çalıştırın: python extract_zendesk_log.py.
İşlemi İzleyin: Betik, işlenen ticket sayısını gösteren ilerleme güncellemelerini konsola yazdıracaktır. Toplam süre, çekilen data hacmine ve Zendesk'in uyguladığı API rate limit sınırlarına bağlıdır. Betik, hız sınırı yanıtlarını yönetmek için gerekli temel mantığı içerir.
Event Log'u Alın: İşlem başarıyla tamamlandığında betik, bulunduğu dizinde zendesk_event_log.csv isimli bir dosya oluşturacaktır. Bu dosya, analiz için yapılandırılmış event log verilerini içerir.
Yükleme İçin Hazırlık: zendesk_event_log.csv dosyasını açarak doğru şekilde oluşturulduğundan emin olun. Sütunların gerekli öznitelikler.le eşleştiğini doğrulayın: ServiceRequest, (ActivityName), StartTime, SourceSystem ve LastDataUpdate. Dosya artık Process Mining aracına yüklenmeye hazırdır.

Konfigürasyon

API Kimlik Bilgileri: Betik, geçerli bir Zendesk alt alan adı, bir acente veya yönetici kullanıcının e-posta adresi ve aktif bir API anahtarı gerektirir. Kimlik bilgileriyle ilişkili kullanıcının biletleri, bilet denetimlerini, kullanıcıları ve bilet metriklerini okuma izinlerine sahip olması gerekir.
Tarih Aralığı: Veri çıkarma işleminin başlangıç tarihi, betikteki START_TIMESTAMP değişkeni tarafından kontrol edilir ve bu bir Unix epoch zaman damgası (zaman damgası) olmalıdır. Daha büyük bir geçmiş veri çekme işlemine başlamadan önce betiğin çıktısını ve performansını doğrulamak için 3 ay gibi daha kısa bir süreyle başlamak tavsiye edilir.
Artımlı Dışa Aktarma API'si: Bu çözüm, Zendesk'in Artımlı Dışa Aktarma API'sini kullanır. Bu, toplu veri dışa aktarımı için tasarlandığından ve yaygın sayfalama (pagination) sorunlarını önlediğinden, çok sayıda bilet getirmek için en verimli ve önerilen yöntemdir.
Performans ve Hız Sınırlandırması: Zendesk, abonelik planına göre değişen API hız sınırları uygular. Betik, API tarafından döndürülen Retry-After başlığına dayanarak bir hız sınırına ulaşıldığında yürütmeyi duraklatmak için dahili mantığa sahiptir. Çok büyük örneklerde, veri çıkarma işlemi birkaç saat sürebilir.
Ön Koşullar: Bu veri çıkarma yöntemi, çalışan bir Python 3.6+ ortamı ve requests harici kütüphanesini gerektirir. Gerekli API anahtarını oluşturmak için hedef Zendesk örneğine yönetici erişimi zorunludur.

a Örnek Sorgu python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
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', API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'An error occurred: {e}')
            break

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

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

Adımlar

Zendesk API Erişimini Hazırlayın: Zendesk'e yönetici olarak giriş yapın. Admin Center'a gidin, ardından Apps and integrations > APIs > Zendesk API yolunu izleyin. Settings sekmesi altında Token Access özelliğinin etkinleştirildiğinden emin olun. 'Add API token' butonuna tıklayarak yeni bir belirteç oluşturun. Belirteci bir daha görüntülenemeyeceği için güvenli bir yere kopyalayın.
Python Ortamını Kurun: Python 3.6 veya daha yeni bir sürümün yüklü olduğundan emin olun. Zendesk API'sine HTTP istekleri göndermek için gerekli olan requests kütüphanesini kurun. Komut satırına pip install requests yazarak yükleme yapabilirsiniz.
Python Betiğini Yapılandırın: Size sağlanan Python betiğini extract_zendesk_log.py gibi bir isimle kaydedin. Dosyayı bir metin düzenleyicide açarak üst kısımdaki yer tutucu değişkenleri (ZENDESK_SUBDOMAIN, ZENDESK_EMAIL ve API_TOKEN) kendi Zendesk bilgilerinizle güncelleyin.
Data Çekme Aralığını Belirleyin: Betik içindeki START_TIMESTAMP değişkenini bulun. Bu değer, data çekme işleminin başlangıç tarihini belirler. Bir Unix epoch zaman damgası (zaman damgası) formatında olmalıdır. İlk analiz için son 3-6 ayı kapsayan bir değer girmeniz önerilir.
Betiği Çalışanştırın: Terminali veya komut istemini açın, betiği kaydettiğiniz dizine gidin ve şu komutu çalıştırın: python extract_zendesk_log.py.
İşlemi İzleyin: Betik, işlenen ticket sayısını gösteren ilerleme güncellemelerini konsola yazdıracaktır. Toplam süre, çekilen data hacmine ve Zendesk'in uyguladığı API rate limit sınırlarına bağlıdır. Betik, hız sınırı yanıtlarını yönetmek için gerekli temel mantığı içerir.
Event Log'u Alın: İşlem başarıyla tamamlandığında betik, bulunduğu dizinde zendesk_event_log.csv isimli bir dosya oluşturacaktır. Bu dosya, analiz için yapılandırılmış event log verilerini içerir.
Yükleme İçin Hazırlık: zendesk_event_log.csv dosyasını açarak doğru şekilde oluşturulduğundan emin olun. Sütunların gerekli öznitelikler.le eşleştiğini doğrulayın: ServiceRequest, (ActivityName), StartTime, SourceSystem ve LastDataUpdate. Dosya artık Process Mining aracına yüklenmeye hazırdır.

Konfigürasyon

API Kimlik Bilgileri: Betik, geçerli bir Zendesk alt alan adı, bir acente veya yönetici kullanıcının e-posta adresi ve aktif bir API anahtarı gerektirir. Kimlik bilgileriyle ilişkili kullanıcının biletleri, bilet denetimlerini, kullanıcıları ve bilet metriklerini okuma izinlerine sahip olması gerekir.
Tarih Aralığı: Veri çıkarma işleminin başlangıç tarihi, betikteki START_TIMESTAMP değişkeni tarafından kontrol edilir ve bu bir Unix epoch zaman damgası (zaman damgası) olmalıdır. Daha büyük bir geçmiş veri çekme işlemine başlamadan önce betiğin çıktısını ve performansını doğrulamak için 3 ay gibi daha kısa bir süreyle başlamak tavsiye edilir.
Artımlı Dışa Aktarma API'si: Bu çözüm, Zendesk'in Artımlı Dışa Aktarma API'sini kullanır. Bu, toplu veri dışa aktarımı için tasarlandığından ve yaygın sayfalama (pagination) sorunlarını önlediğinden, çok sayıda bilet getirmek için en verimli ve önerilen yöntemdir.
Performans ve Hız Sınırlandırması: Zendesk, abonelik planına göre değişen API hız sınırları uygular. Betik, API tarafından döndürülen Retry-After başlığına dayanarak bir hız sınırına ulaşıldığında yürütmeyi duraklatmak için dahili mantığa sahiptir. Çok büyük örneklerde, veri çıkarma işlemi birkaç saat sürebilir.
Ön Koşullar: Bu veri çıkarma yöntemi, çalışan bir Python 3.6+ ortamı ve requests harici kütüphanesini gerektirir. Gerekli API anahtarını oluşturmak için hedef Zendesk örneğine yönetici erişimi zorunludur.

a Örnek Sorgu python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
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', API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'An error occurred: {e}')
            break

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

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

Adımlar

Zendesk Explore'a Gidin: Zendesk hesabınıza giriş yapın, üst çubuktaki ürün başlatıcı simgesine tıklayın ve Explore'u seçerek ürünü açın.
Yeni Bir Sorgu Oluşturun: Explore içinde sol kenar çubuğundaki Sorgular simgesine, ardından sağ üstteki "New query" düğmesine tıklayın.
Dataset Seçin: "Choose a dataset" penceresinde Support: Tickets dataset seçeneğini belirleyin. Bu dataset, temel ticket niteliklerini ve ana event zaman damgası (zaman damgası) değerlerini içerir.
Metrik Ekleyin: Sorgu oluşturucuda "Metrics" paneline giderek "Add"e tıklayın. COUNT(Tickets) seçimini yapın. Bu, data hacmini doğrulamanıza yardımcı olur.
Satırlara Öznitelikler Ekleyin: "Rows" paneline gidin ve "Add"e tıklayın. Geniş formatlı dışa aktarma dosyanızın temel sütunlarını oluşturacak şu nitelikleri ekleyin:
- Ticket ID (Bu sizin case tanımlayıcı değerinizdir, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestType)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Satırlara Aktivite zaman damgası (zaman damgası) Değerlerini Ekleyin: "Rows" paneline aşağıdaki zaman damgası (zaman damgası) niteliklerini ekleyin. Bunların her biri potansiyel bir aktiviteyi temsil eder. Bazı aktiviteler için özel hesaplanmış bir öznitelik oluşturmanız gerekebilir.
- Ticket created - zaman damgası (zaman damgası): Service Request Created ve Initial Acknowledgment Sent için.
- Ticket assigned - zaman damgası (zaman damgası): Request Assigned To Agent için.
- First reply time - zaman damgası (zaman damgası): First Agent Public Reply Sent için.
- Ticket solved - zaman damgası (zaman damgası): Service Request Resolved ve Satisfaction Survey Sent için.
- Ticket reopened - zaman damgası (zaman damgası): Service Request Reopened için.
- Satisfaction rating received - zaman damgası (zaman damgası): Satisfaction Rating Received için.
- Ticket closed - zaman damgası (zaman damgası): Service Request Closed için.
Diğer Aktiviteler İçin Özel Hesaplanmış Öznitelikler Oluşturun: Bazı aktiviteler belirli alan değişikliklerine dayalıdır ve zaman damgası (zaman damgası) değerlerini yakalamak için özel öznitelik oluşturulmasını gerektirir. Hesaplamalar menüsüne (hesap makinesi simgesi) gidin ve "Standard calculated nitelik" seçeneğini belirleyin. Aşağıdaki her bir aktivite için bir öznitelik oluşturun (Zendesk örneğinizdeki alan ve değerlerin tam adlarını kullanmanız gerekecektir):
- Ad: zaman damgası (zaman damgası) - Categorized and Prioritized. Formül: IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - zaman damgası (zaman damgası)] ENDIF. Oluşturduktan sonra bu yeni özniteliği "Rows" paneline ekleyin ve aggregator değerini MIN olarak değiştirin.
- Ad: zaman damgası (zaman damgası) - Info Requested. Formül: IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - zaman damgası (zaman damgası)] ENDIF. "Rows" paneline ekleyin ve aggregator'ı MIN yapın.
- Ad: zaman damgası (zaman damgası) - Customer Responded. Formül: IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - zaman damgası (zaman damgası)] ENDIF. "Rows" paneline ekleyin ve aggregator'ı MIN yapın.
- Ad: zaman damgası (zaman damgası) - Escalated. Formül: IF ([Changes - Field name] = "group") THEN [Update - zaman damgası (zaman damgası)] ENDIF. "Rows" paneline ekleyin ve aggregator'ı MIN yapın.
- Ad: zaman damgası (zaman damgası) - SLA Breach. Formül: IF ([SLA breach status]=TRUE) THEN [SLA update - zaman damgası (zaman damgası)] ENDIF. "Rows" paneline ekleyin ve aggregator'ı MIN yapın.
Data Filtreleme: "Filters" paneline gidip "Add"e tıklayın. Ticket created - Date için bir filtre ekleyin ve dataset'i yönetilebilir tutmak için son 3-6 ay gibi uygun bir tarih aralığı seçin.
Raporu Çalışanştırın ve Dışa Aktarın: Sorguyu kaydetmek için "Save"e tıklayın. Tablo verileri gösterdiğinde "Export" düğmesine tıklayarak CSV veya Excel gibi tercih ettiğiniz formatı seçin.
Data'yı Event Log Formatına Dönüştürün: Dışa aktarılan dosya, her satırın bir ticket ve her sütunun bir event zaman damgası (zaman damgası) olduğu "wide" formatındadır. Process Mining için bunu "long" formata dönüştürmeniz gerekir. Bunun için Microsoft Excel (Power Query'deki Unpivot özelliğiyle), Python veya benzeri bir data hazırlama aracı kullanın.
- Her satır (ticket) için, boş olmayan her zaman damgası (zaman damgası) sütununa karşılık gelecek şekilde birden fazla yeni satır oluşturun.
- Nihai tabloda ServiceRequest, (ActivityName), StartTime gibi sütunlar bulunmalı ve diğer öznitelikler. her bir service request aktivitesi için yinelenmelidir.

Konfigürasyon

Veri Kümesi: Kullanılacak birincil veri kümesi Support: Tickets'tır. Bu, tek bir sorguda çoğu bilet özelliğine ve temel zaman damgalarına erişim sunar.
İzinler: Sorgu oluşturmak ve kaydetmek için Zendesk Explore'da en az Editör veya Yönetici rolüne sahip olmanız gerekir.
Tarih Aralığı: Ticket created - Date alanına bir tarih aralığı filtresi ayarlamak büyük önem taşır. Performans ile önemli bilgiyü dengelemek için 3 ila 6 aylık bir veri aralığı önerilir. Milyonlarca bileti dışa aktarmak yavaş olabilir veya başarısız olabilir.
Sorgu Filtreleri: Analizi belirli bir hizmete veya ekibe odaklamak için Ticket brand, Ticket form veya Ticket group gibi belirli bilet özelliklerine filtreler eklemeyi düşünebilirsiniz.
Hesaplanmış Öznitelikler: Bu yöntem, durum değişiklikleri veya eskalasyonlar gibi varsayılan nitelikler olmayan olaylar için zaman damgalarını yakalamak amacıyla standart hesaplanmış nitelikler oluşturmaya büyük ölçüde dayanır. Bu nitelikleri oluşturma izinlerine sahip olduğunuzdan emin olun.

a Örnek Sorgu config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Müşteri Enerji ve Altyapıi `Data` Şablonunuz

Müşteri Enerji ve Altyapıi `Data` Şablonunuz

Müşteri Enerji ve Altyapıi Öznitelikleri

Müşteri Enerji ve Altyapıi Etkinlikleri

Veri Çıkarma Kılavuzları

Rapor ve Veri İhracatı için Zendesk Explore UI

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 için Zendesk Artımlı Dışa Aktarımlar API'sı

Adımlar

Konfigürasyon

a Örnek Sorgu python

Zendesk İçin Üçüncü Taraf ETL Aracı Bağlayıcısı

Adımlar

Konfigürasyon

a Örnek Sorgu config

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

Müşteri Enerji ve Altyapıi Darboğazlarını Sonlandırın, CSAT'ı Şimdi Artırın

Müşteri Enerji ve Altyapıi Data Şablonunuz

Müşteri Enerji ve Altyapıi Data Şablonunuz

Müşteri Enerji ve Altyapıi Öznitelikleri

Müşteri Enerji ve Altyapıi Etkinlikleri

Veri Çıkarma Kılavuzları

Rapor ve Veri İhracatı için Zendesk Explore UI

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 için Zendesk Artımlı Dışa Aktarımlar API'sı

Adımlar

Konfigürasyon

a Örnek Sorgu python

Zendesk İçin Üçüncü Taraf ETL Aracı Bağlayıcısı

Adımlar

Konfigürasyon

a Örnek Sorgu config

Gizliliğinize önem veriyoruz

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

Müşteri Enerji ve Altyapıi Darboğazlarını Sonlandırın, CSAT'ı Şimdi Artırın

Müşteri Enerji ve Altyapıi `Data` Şablonunuz

Müşteri Enerji ve Altyapıi `Data` Şablonunuz