Müşteri Enerji ve Altyapıi Data Şablonunuz
Müşteri Enerji ve Altyapıi Data Şablonunuz
- Önerilen Öznitelikler
- İzlenecek Temel Etkinlikler
- Veri Çekim Kılavuzu
Müşteri Enerji ve Altyapıi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
Activity
|
Müşteri hizmetleri sürecinde gerçekleşen belirli bir iş olayının veya adımının adı. | ||
|
Açıklama
Bu
Neden önemli
Bu
Nereden alınır
Freshdesk içindeki olay tiplerinden türetilmiştir. Bu, 'Tickets' API uç noktasından durum değişikliklerinin ve 'Conversations' uç noktasından notlar veya yanıtlar gibi belirli olayların bir kombinasyonu olabilir.
Örnekler
Bilet Oluşturulduİlk Yanıt GönderildiDurum Beklemede Olarak DeğiştirildiTalep ÇözüldüTalep Kapatıldı
|
|||
|
BT Hizmet Talebi Yönetimi
ServiceRequest
|
Genellikle bir talep veya durum olarak bilinen, tek bir müşteri sorgusunun veya sorununun benzersiz tanımlayıcısı. | ||
|
Açıklama
BT Hizmet Talebi Yönetimi, tek bir müşteri etkileşimiyle ilgili tüm Process Mining'de bu
Neden önemli
Bu, tüm ilgili
Nereden alınır
Bu, Freshdesk'teki birincil talep kimliğidir ve genellikle 'Tickets' API endpoint'indeki 'id' alanı olarak bulunur.
Örnekler
SR-2023-10-4831SR-2023-11-0192SR-2023-11-5210
|
|||
|
Olay Zamanı
EventTime
|
Belirli bir faaliyetin veya olayın ne zaman gerçekleştiğini gösteren zaman damgası (zaman damgası)dır. | ||
|
Açıklama
Event Time veya zaman damgası (zaman damgası), bir etkinliğin gerçekleştiği kesin tarihi ve saati kaydeder. Olayları kronolojik olarak sıralamak ve süreçteki farklı adımlar arasındaki süreleri hesaplamak için kritik bir bileşendir. Kaydedilen her etkinlikte karşılık gelen bir zaman damgası (zaman damgası) olmalıdır. Analizde, bu öznitelik her hizmet talebinin zaman çizelgesini oluşturmak için kullanılır. Çözüm süresi, ilk yanıt süresi ve darboğazların süresi gibi tüm zamanla ilgili KPI'ları hesaplanmasında temel rol oynar. Doğru zaman damgaları, süreç performansını anlamak ve gecikmeleri belirlemek için büyük önem taşır.
Neden önemli
Bu zaman damgası (zaman damgası),
Nereden alınır
Freshdesk API'sindeki talep
Örnekler
2023-10-25T10:00:00Z2023-10-25T10:05:14Z2023-10-26T14:30:00Z
|
|||
|
Atanan Temsilci
AssignedAgent
|
Olayın gerçekleştiği anda talepten sorumlu olan müşteri hizmetleri temsilcisinin adı veya kimliği. | ||
|
Açıklama
Bu Atanan Temsilciye göre
Neden önemli
Bireysel temsilci bazında performans analizine sunar, en iyi performans gösterenleri, eğitim fırsatlarını ve yeniden atamaların etkisini belirlemeye yardımcı olur.
Nereden alınır
Freshdesk 'Tickets' nesnesindeki 'responder_id' alanına karşılık gelir ve bu daha sonra temsilci detaylarıyla birleştirilebilir.
Örnekler
Alice JohnsonRobert SmithMaria Garcia
|
|||
|
BT Hizmet Talebi Yönetimi Türü
ServiceRequestType
|
'Soru', 'Olay', 'Problem' veya 'Özellik Talebi' gibi hizmet talebinin sınıflandırması. | ||
|
Açıklama
BT Hizmet Talebi Yönetimi Türü, müşterinin sorgusunun niteliğini tanımlayan kritik bir kategorizasyon alanıdır. Bu sınıflandırma genellikle talep oluşturulduğunda veya ilk değerlendirme adımında belirlenir ve talebi uygun ekibe veya temsilciye yönlendirmeye yardımcı olur. Analizde, bu
Neden önemli
Olaylar ve sorular gibi farklı müşteri sorunları türleri için performansı ve iş akışlarını karşılaştırmak amacıyla süreç segmentasyonuna sunar.
Nereden alınır
Bu, Freshdesk 'Tickets' nesnesinde mevcut olan 'type' alanıdır.
Örnekler
SoruOlayProblemÖzellik Talebi
|
|||
|
Durum
Status
|
'Açık', 'Beklemede', 'Çözüldü' veya 'Kapalı' gibi hizmet talebinin mevcut veya geçmiş durumu. | ||
|
Açıklama
Durum Durum değişikliklerini izlemek, talebin süreç döngüsünü anlamak için büyük önem taşır. Taleplerin belirli durumlarda ne kadar zaman geçirdiğini belirlemeye yardımcı olur ve bu,
Neden önemli
Durum değişikliklerini izlemek, talep süreç döngüsünü anlamanın ve durumların 'Beklemede' veya 'Müşteri Beklemede' gibi belirli durumlarda ne kadar süre kaldığını belirlemenin anahtarıdır.
Nereden alınır
Freshdesk 'Tickets' nesnesindeki 'status' alanına karşılık gelir. Tarihsel durumların aktivite günlüklerinden çıkarılması gerekir.
Örnekler
AçıkBeklemedeÇözüldüKapalı
|
|||
|
Öncelik
Priority
|
'Düşük', 'Orta', 'Yüksek' veya 'Acil' gibi hizmet talebine atanan öncelik seviyesi. | ||
|
Açıklama
Öncelik Bu
Neden önemli
SLA analizi ve kaynakların yüksek öncelikli sorunları düşük öncelikli olanlardan daha hızlı ele almak için doğru şekilde tahsis edilip edilmediğini anlamak için gereklidir.
Nereden alınır
Freshdesk 'Tickets' nesnesindeki 'priority' alanına karşılık gelir.
Örnekler
DüşükOrtaYüksekAcil
|
|||
|
Atanan Grup
AssignedGroup
|
Hizmet talebinin atandığı ekip veya departman. | ||
|
Açıklama
Atanan Grup, belirli bir hizmet talebini ele almaktan sorumlu temsilci ekibini temsil eder. Talepler genellikle 'Teknik Destek' veya 'Fatura Departmanı' gibi, türlerine veya karmaşıklıklarına göre uzmanlaşmış gruplara yönlendirilir. Bu
Neden önemli
Ekip veya departman düzeyinde performans analizine sunar, el değiştirmeleri vurgular ve gruba özel darboğazları belirler.
Nereden alınır
Freshdesk 'Tickets' nesnesindeki 'group_id' alanına karşılık gelir.
Örnekler
L1 DestekL2 Teknik DestekFaturalandırmaMüşteri Başarısı
|
|||
|
İletişim Kanalı
CommunicationChannel
|
Hizmet talebinin başlatıldığı 'E-posta', 'Telefon', 'Chat' veya 'Web Portalı' gibi kanalı ifade eder. | ||
|
Açıklama
Bu Süreci iletişim kanalına göre analiz etmek, kaynak tahsisini optimize etmeye ve kanal verimliliğini anlamaya yardımcı olur. Hangi kanalların daha hızlı çözümler veya daha yüksek müşteri memnuniyeti ile ilişkili olduğunu ortaya çıkarabilir ve hangi kanallara yatırım yapılacağı veya hangi kanalların tanıtılacağı konusunda stratejik kararlar alınmasına bilgi sunar.
Neden önemli
E-posta, telefon veya sohbet gibi farklı müşteri iletişim kanallarındaki süreç performansını ve verimliliğini analiz etmeye yardımcı olur.
Nereden alınır
Freshdesk 'Tickets' nesnesindeki 'source' alanına karşılık gelir.
Örnekler
E-postaTelefonWeb PortalChat
|
|||
|
İlk Yanıt Süresi
FirstResponseTime
|
Talep oluşturulmasından müşteriye ilk temsilci yanıtına kadar geçen süre. | ||
|
Açıklama
First Response Time, bir müşterinin bir hizmet temsilcisinden otomatik olmayan bir ilk yanıtı ne kadar hızlı aldığını ölçer. 'First Response Sent' etkinliğinin zaman damgası (zaman damgası) ile 'Ticket Created' etkinliğinin zaman damgası (zaman damgası) arasındaki fark olarak hesaplanır. Bu KPI, hizmet duyarlılığının temel bir göstergesidir ve müşteri memnuniyeti üzerinde güçlü bir etkiye sahiptir. Kısa bir First Response Time, müşteriye sorununun anlaşıldığı ve ele alındığı konusunda güvence verir. Bu metriği analiz etmek, kuruluşların ilk yanıt SLA'larını karşıladığından ve hızlı bir müşteri deneyimi sunduğundan emin olmalarına yardımcı olur.
Neden önemli
Müşteri memnuniyetinin anahtar bir faktörü olan hizmet yanıt verme hızını ölçer ve proaktif hizmet sunumu hedefine doğrudan katkıda bulunur.
Nereden alınır
Hesaplanmış alan. 'Bilet Oluşturuldu' olayının zaman damgası (zaman damgası) ile 'İlk Yanıt Gönderildi' olayının zaman damgası (zaman damgası) arasındaki süredir.
Örnekler
3000009000001800000
|
|||
|
Kaynak Sistem
SourceSystem
|
`Data`nın çıkarıldığı sistem, bu durumda 'Freshdesk'tir. | ||
|
Açıklama
Bu Basit gibi görünse de, bu
Neden önemli
Veri yönetişimi ve birden fazla kaynak sistemden gelen
Nereden alınır
Bu,
Örnekler
Freshdesk
|
|||
|
Memnuniyet Puanı
SatisfactionRating
|
Talep çözüldükten sonra müşteri tarafından verilen memnuniyet puanı. | ||
|
Açıklama
Memnuniyet Puanı, genellikle bir talep çözüldükten sonra gönderilen bir anket aracılığıyla toplanan önemli bir sonuç ölçütüdür. Genellikle sayısal bir puan veya 'Memnun', 'Tarafsız' veya 'Memnuniyetsiz' gibi kategorik bir derecelendirmeden oluşur. Bu
Neden önemli
Süreç yürütmeyi müşteri sonuçlarıyla ilişkilendirir, hangi süreç davranışlarının yüksek veya düşük müşteri memnuniyetine yol açtığını belirlemeye yardımcı olur.
Nereden alınır
Bu
Örnekler
5314
|
|||
|
Müşteri Adı
CustomerName
|
Hizmet talebini başlatan müşterinin adı veya kimliği. | ||
|
Açıklama
Bu Müşteriye göre analiz yapmak, hangi müşterilerin en çok talep gönderdiğini veya en çok yeniden açılan sorunları yaşadığını gibi kalıpları ortaya çıkarabilir. Bu, müşteri başarısı girişimlerini bilgilendirebilir ve kötü hizmet deneyimleri nedeniyle ayrılma riski taşıyan müşterileri belirlemeye yardımcı olabilir. Ayrıca birden fazla hizmet talebi genelinde uçtan uca müşteri yolculuğunu anlamak için de büyük önem taşır.
Neden önemli
Müşteri odaklı bir süreç görünümü sunar, sık talepte bulunanları veya tekrar eden sorunlar yaşayan müşterileri belirlemeye yardımcı olur.
Nereden alınır
Bu bilgi, 'Tickets' nesnesindeki 'requester_id' aracılığıyla bağlantılıdır ve Freshdesk'teki 'Contacts' veya 'Users' nesnesine bağlanır.
Örnekler
John DoeJane Smith`Global Tech Inc.`
|
|||
|
SLA Hedef Çözüm Süresi
SlaTargetResolutionTime
|
Hizmet talebini çözmek için sözleşmeyle kararlaştırılan veya hedeflenen süre. | ||
|
Açıklama
Bu Bu, SLA
Neden önemli
Herhangi bir müşteri hizmetleri kuruluşu için temel bir performans göstergesi olan SLA
Nereden alınır
Bu, Freshdesk 'Tickets' nesnesinde 'fr_due_by' (ilk yanıt) veya 'due_by' (çözüm) gibi bir alan olarak mevcut olabilir veya SLA politika kurallarına göre türetilmesi gerekebilir.
Örnekler
2023-10-25T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
|
|||
|
SLA İhlal Edildi mi?
IsSlaBreached
|
Hizmet talebi çözüm süresinin SLA hedefini aşıp aşmadığını gösteren bir boole bayrağı. | ||
|
Açıklama
Bu hesaplanmış Bu
Neden önemli
Hedefini karşılayamayan her durum için net bir işaret sağlayarak SLA
Nereden alınır
Bu, gerçek çözüm zaman damgası (zaman damgası)nı Freshdesk'ten alınan 'SlaTargetResolutionTime' veya 'due_by' alanı ile karşılaştırarak elde edilen hesaplanmış bir alandır.
Örnekler
truefalse
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Verilerin kaynak sistemden son yenilendiği zamanı gösteren `zaman damgası (zaman damgası)dır. | ||
|
Açıklama
Bu Analistler bu bilgiyi,
Neden önemli
Verilerin güncelliğini gösterir, analizlerin ve kararların güncel bilgilere dayanmasını sunar.
Nereden alınır
Bu,
Örnekler
2023-12-01T08:00:00Z
|
|||
|
Temsilci Aktarım Sayısı
AgentTransferCount
|
Bir hizmet talebinin bir temsilciden diğerine yeniden atandığı toplam sayı. | ||
|
Açıklama
Bu 'Ping-pong' olarak da bilinen sık aktarımlar, önemli gecikmelere ve bağlamın her aktarımda kaybolması nedeniyle sinir bozucu bir müşteri deneyimine yol açabilir. Aktarım sayısını analiz etmek, ilk yönlendirme ile ilgili sorunları, temsilci beceri eksikliklerini veya süreç karmaşıklığını belirlemeye yardımcı olur. Amaç genellikle, verimliliği ve müşteri memnuniyetini artırmak için gereksiz aktarımları en aza indirmektir.
Neden önemli
Dahili aktarımların sıklığını ölçer. Bu aktarımlar gecikmelerin ve müşteri memnuniyetsizliğinin önemli bir kaynağı olabilir; ilk seviye çözüm oranının artırılmasına yardımcı olur.
Nereden alınır
Hesaplanmış alan. Bu, her benzersiz BT Hizmet Talebi Yönetimi için 'Ticket Reassigned' etkinliklerinin sayısıdır.
Örnekler
0132
|
|||
|
Ürün
Product
|
Müşterinin talebinin ilgili olduğu ürün veya hizmet. | ||
|
Açıklama
Bu Süreci ürüne göre filtreleyerek, kuruluşlar ürüne özgü sorunları ortaya çıkarabilir. Örneğin, belirli bir ürünün orantısız sayıda destek talebi oluşturup oluşturmadığını veya yeni bir ürün lansmanının sorgularda ani bir artışa neden olup olmadığını vurgulayabilir. Bu analiz, ürün geliştirme ve yönetim ekiplerine değerli geri bildirim sunar.
Neden önemli
Sürecin ürün alanına göre filtrelenmesine sunar, hangi ürünlerin en çok destek talebi oluşturduğunu veya en uzun çözüm sürelerine sahip olduğunu gösteren stratejik bilgiler sunar.
Nereden alınır
Bu genellikle özel bir alandır. Kesin konumu Freshdesk yapılandırmasına bağlıdır ve muhtemelen 'Tickets' API yanıtının 'custom_fields' bölümünde bulunur.
Örnekler
Alpha PlatformBeta Mobil UygulamaGamma Aboneliği
|
|||
|
Yeniden Açıldı mı?
IsReopened
|
Çözümlenmiş bir hizmet talebinin tekrar açılıp açılmadığını gösteren bir boole bayrağı. | ||
|
Açıklama
Bu durum seviyesi Yüksek yeniden açılan talep oranı, ilk çözümün etkili veya eksiksiz olmadığını, bu durumun verimsizliğe ve müşteri memnuniyetsizliğine yol açtığını gösterir. Yeniden açılan talepleri filtreleyerek analistler, yeniden açılmanın yaygın nedenleri, hangi temsilcilerin veya ekiplerin daha yüksek oranlara sahip olduğu ve hangi talep türlerinin yeniden açılmaya en yatkın olduğu gibi kök nedenleri araştırabilir.
Neden önemli
Yeniden işleme gerektiren vakaları belirler; bu, çözüm kalitesi ve süreç verimsizliğinin temel bir göstergesidir. Bu vakaları analiz etmek, ilk temasta çözüm oranını iyileştirmeye yardımcı olur.
Nereden alınır
Hesaplanmış alan. O vaka için Etkinlik = 'Ticket Reopened' olan bir olay mevcutsa, bir BT Hizmet Talebi Yönetimi için doğru (
Örnekler
truefalse
|
|||
Müşteri Enerji ve Altyapıi Etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Bilet Oluşturuldu
|
Bu, müşteri hizmetleri süreç döngüsündeki ilk `event`'tir ve bir müşterinin talebinin Freshdesk'e resmi olarak kaydedildiği anı temsil eder. Bu aktivite, yeni bir talep e-posta, bir portal, telefon veya API entegrasyonu aracılığıyla oluşturulduğunda açıkça yakalanır. | ||
|
Neden önemli
Bu aktivite, her durum için başlangıç noktası olarak olarak kullanılır ve genel çözüm sürelerini hesaplamak ile kanal veya türe göre talep hacmi eğilimlerini analiz etmek için temel bir öneme sahiptir.
Nereden alınır
Bu, Freshdesk 'Ticket Activities' günlüğünde açık bir
Yakala
Oluşturulduğunda doğrudan biletin etkinlik akışına kaydedilir.
Event tipi
explicit
|
|||
|
İlk Yanıt Gönderildi
|
Bilet oluşturulduktan sonra bir temsilci tarafından müşteriye gönderilen ilk herkese açık yanıtı işaretler. Freshdesk, SLA takibi için 'First Response Time'ı ölçmek üzere bu olayı açıkça yakalar. | ||
|
Neden önemli
Bu, müşteri yanıt verme hızını ve SLA
Nereden alınır
Bu, Freshdesk'in SLA amaçları için izlediği belirli bir
Yakala
Biletin konuşma geçmişindeki ilk herkese açık temsilci yanıtıyla belirlenir.
Event tipi
explicit
|
|||
|
Talep Atandı
|
Bir talebin belirli bir temsilciye veya gruba atanmasını temsil eder. Bu `event`, atanan temsilci veya grup alanı doldurulduğunda veya değiştirildiğinde talebin geçmişine açıkça kaydedilir. | ||
|
Neden önemli
Atamaları izlemek, temsilci iş yükünü analiz etmek, yönlendirme verimsizliklerini belirlemek ve atama süresi KPI'larını ölçmek için büyük önem taşır. İşin nasıl dağıtıldığını ve iş başlamadan önce gecikmelerin nerede meydana geldiğini anlamaya yardımcı olur.
Nereden alınır
Zaman damgası ile 'Agent' veya 'Group' alanlarındaki değişikliklerin kaydedildiği 'Ticket Activities' logundan yakalanmıştır.
Yakala
Bir temsilci veya grup için 'Assigned to' alanı güncellendiğinde kaydedilen olay.
Event tipi
explicit
|
|||
|
Talep Çözüldü
|
Temsilcinin bir çözüm sağladığı ve talep durumunu 'Çözüldü' olarak değiştirdiği kilit kilometre taşını temsil eder. Bu, talebin geçmişinde kaydedilen açık bir durum değişikliğidir. | ||
|
Neden önemli
Bu aktivite, bir talep üzerindeki aktif çalışmanın sonunu işaret eder ve çözüm süresini ölçmek için temel oluşturur. Temsilci performansını ve genel süreç verimliliğini analiz etmek için kritik bir
Nereden alınır
Belirli durum değişikliğini 'Resolved' olarak bir zaman damgası (zaman damgası) ile kaydeden 'Ticket Activities' logundan yakalanmıştır.
Yakala
Biletin 'Status' alanı 'Resolved' olarak güncellendiğinde kaydedilen olay.
Event tipi
explicit
|
|||
|
Talep Kapatıldı
|
Bu, talebin kalıcı olarak kapatılmasını temsil eden nihai aktivitedir. Genellikle, 'Çözüldü' durumunda herhangi bir yeni müşteri yanıtı olmaksızın belirli bir süre kaldıktan sonra sistem tarafından otomatik olarak gerçekleştirilir. | ||
|
Neden önemli
Bu aktivite, hizmet talebi süreç döngüsünün kesin sonunu işaret eder. Doğru uçtan uca döngü süresi hesaplamaları için son noktayı sunar.
Nereden alınır
Son durum değişikliğini 'Closed' olarak kaydeden 'Ticket Activities' logundan yakalanmıştır. Bu genellikle bir sistem otomasyonu tarafından tetiklenir.
Yakala
Biletin 'Status' alanı 'Closed' olarak güncellendiğinde kaydedilen olay.
Event tipi
explicit
|
|||
|
Dahili Not Eklendi
|
Bir temsilci, diğer temsilcilerle dahili işbirliği için tasarlanmış, bilete özel bir not ekler. Bu, biletin etkinlik akışında yakalanan ve yalnızca temsilciler tarafından görülebilen açık bir olaydır. | ||
|
Neden önemli
Dahili notları izlemek, işbirliği kalıplarını analiz etmeye ve önemli dahili tartışma gerektiren sorunları belirlemeye yardımcı olur. Çözümden önce yüksek sıklıktaki dahili notlar, karmaşık sorunları veya bilgi eksikliklerini gösterebilir.
Nereden alınır
Talebin konuşma geçmişinde 'Özel Not' olarak kaydedilir ve müşteriye verilen herkese açık yanıtlardan ayırt edilebilir.
Yakala
Bir temsilci 'Private' olarak işaretlenmiş bir not eklediğinde kaydedilen olay.
Event tipi
explicit
|
|||
|
Durum Beklemede Olarak Değiştirildi
|
Bu aktivite, bir temsilci müşteriden `data` beklerken ve talep durumunu 'Beklemede' olarak değiştirdiğinde gerçekleşir. Bu `event`, talebin aktivite geçmişinde bir durum değişikliği olarak açıkça kaydedilir. | ||
|
Neden önemli
Sürecin harici giriş beklerken durakladığı dönemleri belirler. Bu durumda harcanan zamanı analiz etmek, müşteri tarafındaki gecikmeleri ölçmeye ve SLA uyumluluk analizini desteklemeye yardımcı olur, çünkü SLA zamanlayıcıları genellikle bu durumda duraklatılır.
Nereden alınır
Beklemede durumuna geçiş dahil olmak üzere tüm durum değişikliklerini kaydeden 'Ticket Activities' logundan yakalanmıştır.
Yakala
Biletin 'Status' alanı 'Pending' olarak güncellendiğinde kaydedilen olay.
Event tipi
explicit
|
|||
|
Memnuniyet Anketi Gönderildi
|
Müşteri memnuniyeti anketinin gönderilmesini temsil eder ve genellikle bir talep çözüldükten sonra otomasyon kuralı tarafından tetiklenir. Otomasyon eylemi talebin geçmişine kaydedilirse bu `event` yakalanabilir. | ||
|
Neden önemli
Geri bildirim toplama sürecinin başlangıcını işaretler. Anket yanıtlarını süreç varyantlarıyla ilişkilendirmek, süreç performansının müşteri memnuniyetini nasıl etkilediğine dair derinlemesine stratejik bilgiler sağlayabilir.
Nereden alınır
Bu, genellikle bir 'Otomasyon Kuralı' tarafından tetiklenir. Talebin aktivite günlüğünde ayrı bir
Yakala
Bilet çözüldükten sonra bir otomasyon kuralı yürütmesi tarafından kaydedilen olay.
Event tipi
explicit
|
|||
|
Müşteri Yanıtladı
|
Müşteriden alınan yeni bir yanıtı veya iletişimi temsil eder. Bu, talebin konuşma dizisindeki açık bir `event`'tir ve genellikle 'Beklemede' durumundan 'Açık' durumuna bir durum değişikliğini tetikler. | ||
|
Neden önemli
Bu aktivite, müşteri etkileşimlerinin karşılıklı doğasını anlamanın ve müşteri yanıt sürelerini ölçmenin anahtarıdır. Ayrıca duraklatılan tüm SLA zamanlayıcılarını yeniden başlatarak
Nereden alınır
Biletin konuşma dizisinde yeni bir giriş olarak kaydedilir. Olay, müşterinin iletişim kaydıyla ilişkilidir.
Yakala
Müşteri tarafından bilete eklenen yeni bir herkese açık not.
Event tipi
explicit
|
|||
|
SLA İhlal Edildi
|
Bir bileti yanıtlamak veya çözmek için geçen sürenin tanımlanan SLA politika hedefini aşması durumunda ortaya çıkan hesaplanmış bir olaydır. Freshdesk SLA durumunu izler ve biletleri 'ihlal edildi' olarak işaretler; bu da bu etkinliği türetmek için kullanılabilir. | ||
|
Neden önemli
Bu aktivite, hizmet seviyesi taahhütlerinin tam olarak ne zaman ve nerede karşılanmadığını belirterek SLA
Nereden alınır
Bu
Yakala
Bilet verilerinden, 'Time to Resolve'ın 'SLA Target Resolution Time'ı aştığı durumlarda türetin.
Event tipi
calculated
|
|||
|
Talep Önceliği Değiştirildi
|
Bu `event`, bir temsilcinin veya otomasyon kuralının bir talebin öncelik seviyesini, örneğin 'Düşük'ten 'Yüksek'e değiştirmesiyle gerçekleşir. Bu, talebin aktivite günlüğünde açık bir güncelleme olarak kaydedilir. | ||
|
Neden önemli
Öncelikteki değişiklikler, eskalasyonları veya sorunun aciliyetinin yeniden değerlendirilmesini işaret edebilir. Bu değişiklikleri analiz etmek, eskalasyon nedenlerini ve çözüm süresi üzerindeki etkilerini anlamaya yardımcı olur.
Nereden alınır
Bilet özelliklerindeki 'Priority' alanı dahil tüm değişiklikleri kaydeden 'Ticket Activities' logundan yakalanmıştır.
Yakala
Öncelik' alanının değeri güncellendiğinde kaydedilen olay.
Event tipi
explicit
|
|||
|
Talep Yeniden Atandı
|
İlk atamadan sonra bir talep, bir temsilciden veya gruptan diğerine aktarıldığında gerçekleşir. Bu, talebin etkinlik günlüğünde sahip değişikliği olarak yakalanan açık bir `event`'tir. | ||
|
Neden önemli
Sık yeniden atamalar veya yüksek temsilciden temsilciye aktarım oranı, genellikle yanlış ilk yönlendirmeyi veya izole bilgiyi gösterir. Bu analiz, ilk temasta çözüm oranını iyileştirme fırsatlarını belirlemeye yardımcı olur.
Nereden alınır
İlk atamadan sonra 'Ticket Activities' günlüğündeki 'Agent' veya 'Group' alanlarındaki değişiklikler aracılığıyla izlenir.
Yakala
İlk atama yapıldıktan sonra 'Atanan kişi' alanında yapılan sonraki bir güncelleme.
Event tipi
explicit
|
|||
|
Ticket Yeniden Açıldı
|
Bu aktivite, bir müşteri, zaten 'Çözüldü' durumunda olan bir talebe yanıt verdiğinde gerçekleşir ve bu da otomatik olarak durumunu 'Açık' olarak değiştirir. Bu, sistem tarafından kaydedilen açık bir `event`'tir. | ||
|
Neden önemli
Yüksek tekrar açılma oranı, ilk çözümlerin etkili olmadığını, bu durumun yeniden işleme ve müşteri memnuniyetsizliğine yol açtığını gösterir. Bu etkinliği analiz etmek, 'Ticket Re-opening Analysis' ve ilk temasta çözüm oranını iyileştirmek için büyük önem taşır.
Nereden alınır
Bu
Yakala
Müşteri etkileşimi tarafından tetiklenen 'Çözüldü' durumundan 'Açık' durumuna geçiş.
Event tipi
explicit
|
|||