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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
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?dir?
Ö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?dir?
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?dir?
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
|
|||