Müşteri Hizmetleri Data Template'iniz
Müşteri Hizmetleri Data Template'iniz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Veri Çekim Rehberliği
Müşteri Hizmetleri Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
Activity
|
Müşteri hizmetleri sürecinde gerçekleşen belirli bir iş `event`'inin 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ı
|
|||
|
Hizmet Talebi
ServiceRequest
|
Genellikle bir talep veya durum olarak bilinen, tek bir müşteri sorgusunun veya sorununun benzersiz tanımlayıcısı. | ||
|
Açıklama
Hizmet Talebi, 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 event'in ne zaman gerçekleştiğini gösteren zaman damgasıdır. | ||
|
Açıklama
Event Time veya 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ı 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ı hesaplamak için temeldir. Doğru zaman damgaları, süreç performansını anlamak ve gecikmeleri belirlemek için hayati öneme sahiptir.
Neden önemli
Bu 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 olanak tanır, 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
|
|||
|
Çözüm Süresi
ResolutionTime
|
Bir hizmet talebinin oluşturulduğu andan çözüldüğü ana kadar geçen toplam süre. | ||
|
Açıklama
Çözüm Süresi, hizmet sürecinin uçtan uca süresini ölçen kritik bir durum seviyesi KPI'ıdır. 'Talep Çözüldü' Bu
Neden önemli
Bu, süreç verimliliğini ölçmek için birincil bir KPI olup, bir müşterinin sorununu baştan sona çözmek için geçen toplam süreyi gösterir.
Nereden alınır
Hesaplanmış alan. Her Hizmet Talebi için ilk olayın zaman damgası (oluşturma) ile 'Bilet Çözüldü' olayının zaman damgası arasındaki süredir.
Örnekler
25920000086400000604800000
|
|||
|
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 yaşam döngüsünü anlamak için temeldir. Taleplerin belirli durumlarda ne kadar zaman geçirdiğini belirlemeye yardımcı olur ve bu,
Neden önemli
Durum değişikliklerini izlemek, talep yaşam 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
Örnekler
AçıkBeklemedeÇözüldüKapalı
|
|||
|
Hizmet Talebi Türü
ServiceRequestType
|
'Soru', 'Olay', 'Problem' veya 'Özellik Talebi' gibi hizmet talebinin sınıflandırması. | ||
|
Açıklama
Hizmet Talebi 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 olanak tanır.
Nereden alınır
Bu, Freshdesk 'Tickets' nesnesinde mevcut olan 'type' alanıdır.
Örnekler
SoruOlayProblemÖzellik Talebi
|
|||
|
Ö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 esastır.
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 olanak tanır, 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 sağlar.
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ı ile 'Ticket Created' etkinliğinin 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ı ile 'İlk Yanıt Gönderildi' olayının 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 kritik öneme sahiptir.
Neden önemli
Müşteri odaklı bir süreç görünümü sağlar, 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ı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 `timestamp`. | ||
|
Açıklama
Bu Analistler bu bilgiyi,
Neden önemli
Verilerin güncelliğini gösterir, analizlerin ve kararların güncel bilgilere dayanmasını sağlar.
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 Hizmet Talebi 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 sağlar.
Neden önemli
Sürecin ürün alanına göre filtrelenmesine olanak tanır, hangi ürünlerin en çok destek talebi oluşturduğunu veya en uzun çözüm sürelerine sahip olduğunu gösteren içgörüler 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 Hizmet Talebi için doğru (
Örnekler
truefalse
|
|||
Müşteri Hizmetleri Etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Bilet Oluşturuldu
|
Bu, müşteri hizmetleri yaşam 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
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 kritik öneme sahiptir. İş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
Nereden alınır
Belirli durum değişikliğini 'Resolved' olarak bir 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 `aktivite`dir. 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
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 içgörüler sağlayabilir.
Nereden alınır
Bu, genellikle bir 'Otomasyon Kuralı' tarafından tetiklenir. Talebin
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
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
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 hayati öneme sahiptir.
Nereden alınır
Bu
Yakala
Müşteri etkileşimi tarafından tetiklenen 'Çözüldü' durumundan 'Açık' durumuna geçiş.
Event tipi
explicit
|
|||