Müşteri hizmetleri veri şablonunuz
Müşteri hizmetleri veri şablonunuz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Veri çıkarma yönergeleri
Müşteri hizmetleri öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Etkinlik
Activity
|
Müşteri hizmetleri sürecinde gerçekleşen belirli bir iş olayının veya adımın adı. | ||
|
Açıklama
Etkinlik özniteliği, bir hizmet talebinin yaşam döngüsündeki belirli bir işlemi veya durum değişikliğini ifade eder. Destek talebinin oluşturulması, atanması, ilk yanıtın gönderilmesi ve talebin çözülmesi gibi önemli iş olaylarını kaydeder. Bu etkinlikler süreç haritasındaki düğümleri oluşturur. Bu etkinliklerin sırasını ve sıklığını analiz etmek, Process Mining’in temelini oluşturur. Süreç akışlarını görselleştirmenizi, sık ve nadir görülen yolları belirlemenizi ve standart işleyişten sapmaları tespit etmenizi sağlar. Etkinlikleri anlamak; verimsizlikleri, Destek talebinin yeniden açılması gibi yeniden çalışma döngülerini ve uyumluluk sorunlarını belirlemek açısından önemlidir.
Neden önemli?
Bu öznitelik, süreç haritasındaki adımları tanımlar ve süreç akışını başlangıçtan bitişe kadar görselleştirip analiz etmenizi sağlar.
Nereden alınır?
Freshdesk’teki olay türlerinden elde edilir. Tickets API uç noktasındaki durum değişiklikleriyle Conversations uç noktasındaki not veya yanıt gibi belirli olayların birleştirilmesiyle oluşturulabilir.
Örnekler
Destek talebi oluşturulduİlk yanıt gönderildiDurum beklemede olarak değiştirildiDestek talebi çözüldüDestek talebi kapatıldı
|
|||
|
Hizmet talebi
ServiceRequest
|
Tek bir müşteri sorusunu veya sorununu tanımlayan, genellikle destek talebi ya da vaka olarak bilinen benzersiz kimlik. | ||
|
Açıklama
Hizmet talebi, tek bir müşteri etkileşimiyle ilgili tüm etkinlikleri birbirine bağlayan temel vaka kimliğidir. Her yeni müşteri sorusu, sorunu veya talebi için benzersiz bir Hizmet Talebi Kimliği oluşturulur. Bu kimlik, destek talebinin oluşturulmasından atanmasına, çözülmesine ve kapatılmasına kadar tüm yaşam döngüsü boyunca değişmez. Process Mining’de bu öznitelik, her müşteri vakasının uçtan uca yolculuğunu yeniden oluşturmak için temel oluşturur. Analistler, ilgili tüm olayları tek bir Hizmet Talebi Kimliği altında gruplayarak süreç akışlarını görselleştirebilir, çevrim sürelerini ölçebilir ve vakaları etkileyen farklılıkları ya da darboğazları belirleyebilir.
Neden önemli?
Bu temel Vaka kimliği, ilgili tüm olayları tek bir süreç örneğinde birleştirerek her müşteri hizmetleri yolculuğunun eksiksiz görünmesini sağlar.
Nereden alınır?
Bu, Freshdesk’teki temel destek talebi kimliğidir. Genellikle Tickets API uç noktasındaki id alanında bulunur.
Örnekler
SR-2023-10-4831SR-2023-11-0192SR-2023-11-5210
|
|||
|
Olay zamanı
EventTime
|
Belirli bir etkinliğin veya olayın ne zaman gerçekleştiğini gösteren zaman damgası. | ||
|
Açıklama
Olay zamanı, yani zaman damgası, bir etkinliğin gerçekleştiği kesin tarih ve saati kaydeder. Olayları kronolojik sıraya koymak ve süreçteki farklı adımlar arasındaki süreleri hesaplamak için gereklidir. Kaydedilen her etkinliğin 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ğazlarda geçen süre gibi zamanla ilgili tüm KPI’ların hesaplanmasının temelini oluşturur. Süreç performansını anlamak ve gecikmeleri belirlemek için zaman damgalarının doğru olması gerekir.
Neden önemli?
Bu zaman damgası, olayları kronolojik sıraya koymak ve çevrim süreleri ile SLA uyumluluğu gibi süreye dayalı tüm metrikleri hesaplamak için gereklidir.
Nereden alınır?
Freshdesk API’sinde destek talebi olayları, yanıtlar veya durum değişiklikleriyle ilişkili created_at ya da updated_at alanlarına karşılık gelir.
Örnekler
2023-10-25T10:00:00Z2023-10-25T10:05:14Z2023-10-26T14:30:00Z
|
|||
|
Atanan çalışan
AssignedAgent
|
Olayın gerçekleştiği sırada destek talebinden sorumlu müşteri hizmetleri çalışanının adı veya kimliği. | ||
|
Açıklama
Bu öznitelik, hizmet talebiyle ilgilenmek üzere atanan çalışanı belirtir. Yeniden atamalar veya üst kademeye aktarımlar nedeniyle destek talebinin yaşam döngüsü boyunca atanan çalışan değişebilir. Atanan çalışana göre veri analizi, performans yönetimi Dashboardları için önemlidir. Ortalama çözüm süresi, destek talebi hacmi ve yeniden açılma oranı gibi çalışana özel KPI’ları ölçmenizi sağlar. Böylece en iyi performans gösteren çalışanları belirleyebilir, eğitim ihtiyaçlarını ortaya çıkarabilir ve çalışanlar arasındaki aktarımların toplam çözüm süresine etkisini inceleyebilirsiniz.
Neden önemli?
Çalışan bazında performans analizi yapmanızı sağlar; en iyi performans gösterenleri, eğitim fırsatlarını ve yeniden atamaların etkisini belirlemenize yardımcı olur.
Nereden alınır?
Freshdesk Tickets nesnesindeki responder_id alanına karşılık gelir. Bu alan, çalışan ayrıntılarıyla birleştirilebilir.
Örnekler
Alice JohnsonRobert SmithMaria Garcia
|
|||
|
Durum
Status
|
Hizmet talebinin mevcut veya geçmişteki durumu. Örneğin 'Açık', 'Beklemede', 'Çözüldü' ya da 'Kapatıldı'. | ||
|
Açıklama
Durum özniteliği, hizmet talebinin belirli bir andaki durumunu gösterir. Durum değişiklikleri genellikle süreçteki önemli aşamaları belirtir. Örneğin, müşteriden bilgi beklenirken 'Açık' durumundan 'Beklemede' durumuna geçilir; müşteri yanıt verdiğinde ise 'Beklemede' durumundan 'Açık' durumuna dönülür. Durum değişikliklerini izlemek, talebin yaşam döngüsünü anlamanın temelidir. Biletlerin belirli durumlarda ne kadar kaldığını görmenize ve darboğazları belirlemenize yardımcı olur. Örneğin, 'Beklemede' durumunun uzun sürmesi, müşterilerden bilgi alınmasında gecikme olduğunu gösterebilir.
Neden önemli?
Durum değişikliklerini izlemek, biletlerin yaşam döngüsünü anlamak ve vakaların 'Beklemede' ya da 'Bekletildi' gibi belirli durumlarda ne kadar kaldığını belirlemek açısından önemlidir.
Nereden alınır?
Freshdesk Tickets nesnesindeki 'status' alanına karşılık gelir. Geçmiş durumlar, etkinlik günlüklerinden çıkarılmalıdır.
Örnekler
AçıkBeklemedeÇözüldüKapatıldı
|
|||
|
Hizmet talebi türü
ServiceRequestType
|
Soru, Olay, Sorun veya Özellik isteği gibi hizmet talebinin sınıflandırması. | ||
|
Açıklama
Hizmet talebi türü, müşterinin başvurusunun niteliğini belirleyen önemli bir sınıflandırma alanıdır. Bu sınıflandırma genellikle destek talebi oluşturulurken veya ilk değerlendirme sırasında belirlenir ve talebin uygun ekibe ya da çalışana yönlendirilmesine yardımcı olur. Analizde bu öznitelik, farklı talep türlerinin nasıl ele alındığını anlamak için süreci gruplara ayırmanızı sağlar. Örneğin, Olayların çözümü Sorulardan daha mı uzun sürüyor? veya En sık hangi talep türleri yeniden açılıyor? gibi soruları yanıtlamanıza yardımcı olur. Bu gruplandırma, talep türlerine özgü darboğazları belirlemek ve iş akışlarını buna göre iyileştirmek açısından önemlidir.
Neden önemli?
Olaylar ve sorular gibi farklı müşteri sorunlarının performansını ve iş akışlarını karşılaştırmak için süreci gruplara ayırmanızı sağlar.
Nereden alınır?
Bu, muhtemelen Freshdesk Tickets nesnesindeki type alanıdır.
Örnekler
SoruOlaySorunÖzellik talebi
|
|||
|
Öncelik
Priority
|
Hizmet talebine atanan öncelik düzeyi. Örneğin 'Düşük', 'Orta', 'Yüksek' ya da 'Acil'. | ||
|
Açıklama
Öncelik özniteliği, hizmet talebinin ne kadar acil olduğunu gösterir ve genellikle hedef yanıt ile çözüm sürelerini belirler. Öncelik, kurallara göre otomatik olarak ayarlanabilir veya önceliklendirme sırasında bir temsilci tarafından elle belirlenebilir. Bu öznitelik, SLA uyumluluğunu ve kaynak dağılımını analiz etmek için gereklidir. Analistler, süreç haritasını önceliğe göre filtreleyerek yüksek öncelikli biletlerin gerçekten düşük öncelikli olanlardan daha hızlı ele alınıp alınmadığını görebilir. Ayrıca yeniden çalışmaya yol açan öncelik değişikliklerinin ne kadar sık yaşandığını ve süreci nasıl etkilediğini anlamaya yardımcı olur.
Neden önemli?
SLA analizi ve yüksek öncelikli sorunlara düşük öncelikli olanlardan daha hızlı müdahale etmek için kaynakların doğru dağıtılıp dağıtılmadığını anlamak açısından önemlidir.
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 temsilcilerden oluşan ekibi belirtir. Biletler, türlerine veya karmaşıklıklarına göre genellikle 'Teknik destek' ya da 'Faturalandırma departmanı' gibi uzman gruplara yönlendirilir. Bu öznitelik, departmanlar arasındaki devir teslimleri ve ekip performansını analiz etmek için yararlıdır. Hangi grupların en çok bileti ele aldığını, çözüm sürelerinin hangi gruplarda en uzun olduğunu ve biletlerin gruplar arasında ne sıklıkla aktarıldığını belirlemeye yardımcı olur. Bu bilgiler, ekip yapısını ve iş akışlarını iyileştirmek açısından önemlidir.
Neden önemli?
Ekip veya departman düzeyinde performans analizi yapmanızı, devir teslimleri görmenizi ve gruplara özgü darboğazları belirlemenizi sağlar.
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 iletildiği kanal. Örneğin 'E-posta', 'Telefon', 'Sohbet' ya da 'Web portalı'. | ||
|
Açıklama
Bu öznitelik, müşteri iletişiminin kaynağını veya kanalını gösterir. Kanallara göre süreç akışları ve çözüm süreleri farklılık gösterebilir. Örneğin, sohbet üzerinden iletilen bir talebin beklenen çözüm süresi e-postayla gönderilen bir talepten daha kısa olabilir. Süreci iletişim kanalına göre analiz etmek, kaynak dağılımını iyileştirmeye ve kanalların verimliliğini anlamaya yardımcı olur. Hangi kanalların daha hızlı çözümlerle veya daha yüksek müşteri memnuniyetiyle ilişkili olduğunu ortaya çıkarabilir. Bu bilgiler, hangi kanalların öne çıkarılacağı veya hangilerine yatırım yapılacağı konusunda stratejik kararları destekler.
Neden önemli?
E-posta, telefon ve sohbet gibi farklı müşteri iletişim kanallarında 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 portalıSohbet
|
|||
|
İlk yanıt süresi
FirstResponseTime
|
Biletin oluşturulmasıyla bir temsilcinin müşteriye ilk yanıtı vermesi arasında geçen süre. | ||
|
Açıklama
İlk yanıt süresi, müşterinin bir hizmet temsilcisinden otomatik olmayan ilk yanıtı ne kadar hızlı aldığını ölçer. 'İlk yanıt gönderildi' etkinliğinin zaman damgası ile 'Bilet oluşturuldu' etkinliğinin zaman damgası arasındaki fark hesaplanır. Bu KPI, hizmetin yanıt verme hızını gösterir ve müşteri memnuniyetini önemli ölçüde etkiler. İlk yanıt süresinin kısa olması, müşteriye sorununun görüldüğünü ve ele alındığını gösterir. Bu metriği analiz etmek, kuruluşların ilk yanıt SLA’larını karşılamasına ve müşterilere zamanında yanıt vermesine yardımcı olur.
Neden önemli?
Hizmetin yanıt verme hızını ölçer. Bu hız, müşteri memnuniyetini doğrudan etkiler ve proaktif hizmet sunma hedefini destekler.
Nereden alınır?
Hesaplanan bir alandır. 'Bilet oluşturuldu' olayı ile 'İlk yanıt gönderildi' olayı arasındaki zaman damgası farkını gösterir.
Örnekler
3000009000001800000
|
|||
|
Kaynak sistem
SourceSystem
|
Verilerin alındığı sistem. Bu örnekte Freshdesk’tir. | ||
|
Açıklama
Bu öznitelik, süreç verilerinin hangi kaynak uygulamadan geldiğini belirtir. Bu analizde değer sabit olur; örneğin Freshdesk, tüm olayların Freshdesk müşteri hizmetleri platformundan geldiğini gösterir. Basit görünse de bu öznitelik, veri yönetişimi ve birden fazla sistemden gelen verilerin birleştirildiği durumlar için önemlidir. Verilerin kaynağını ve bağlamını açıkça göstererek analistlerin inceledikleri verilerin nereden geldiğini anlamasını sağlar. Veri bütünlüğünü korumak ve analiz sonuçlarına güven oluşturmak için gereklidir.
Neden önemli?
Verilerin kaynağı hakkında gerekli bağlamı sağlar. Veri yönetişimi ve birden fazla kaynak sistemden gelen verileri birleştirirken önem taşır.
Nereden alınır?
Veri kaynağını belirtmek için veri dönüştürme sırasında eklenen sabit Freshdesk değeridir.
Örnekler
Freshdesk
|
|||
|
Memnuniyet puanı
SatisfactionRating
|
Bilet çözüldükten sonra müşterinin verdiği memnuniyet puanı. | ||
|
Açıklama
Memnuniyet puanı, genellikle bilet çözüldükten sonra gönderilen bir anketle toplanan temel bir sonuç metriğidir. Sayısal bir puan veya 'Memnun', 'Kararsız' ya da 'Memnun değil' gibi kategorik bir değerlendirme olabilir. Bu öznitelik, süreç örüntüleriyle müşteri sonuçları arasındaki ilişkiyi incelemenizi sağlar. Kuruluşlar, düşük memnuniyet puanlarına yol açan süreç varyantlarını analiz ederek müşteri deneyimini olumsuz etkileyen davranışları veya gecikmeleri belirleyebilir. Böylece süreç verimliliği ile müşteri memnuniyeti arasındaki ilişki doğrudan görülebilir.
Neden önemli?
Süreç yürütümünü müşteri sonuçlarıyla ilişkilendirerek hangi süreç davranışlarının müşteri memnuniyetini artırdığını veya düşürdüğünü belirlemeye yardımcı olur.
Nereden alınır?
Bu veri, Freshdesk’teki memnuniyet puanları özelliğinin parçasıdır ve Surveys veya Satisfaction Ratings API uç noktası üzerinden alınabilir.
Örnekler
5314
|
|||
|
Müşteri adı
CustomerName
|
Hizmet talebini ileten müşterinin adı veya kimliği. | ||
|
Açıklama
Bu öznitelik, hizmet talebiyle ilişkili müşteriyi belirtir. Belirli bir müşterinin zaman içindeki tüm etkileşimlerini izleyerek süreci müşteri odaklı bir bakış açısıyla analiz etmenizi sağlar. Müşteriye göre yapılan analizler, en çok bileti hangi müşterilerin gönderdiğini veya hangi müşterilerin taleplerinin daha sık yeniden açıldığını ortaya çıkarabilir. Bu bilgiler, müşteri başarısı çalışmalarına yön verebilir ve kötü hizmet deneyimleri nedeniyle müşteri kaybı riski taşıyan müşterileri belirlemeye yardımcı olabilir. Ayrıca birden fazla hizmet talebine yayılan uçtan uca müşteri yolculuğunu anlamak için de önemlidir.
Neden önemli?
Süreci müşteri odaklı bir bakış açısıyla incelemenizi, sık talepte bulunan müşterileri veya aynı sorunları tekrar yaşayanları belirlemenizi sağlar.
Nereden alınır?
Bu bilgi, Tickets nesnesindeki 'requester_id' üzerinden Freshdesk’teki Contacts veya Users nesnesine bağlanır.
Örnekler
John DoeJane SmithGlobal Tech Inc.
|
|||
|
SLA hedef çözüm süresi
SlaTargetResolutionTime
|
Hizmet talebinin çözülmesi için sözleşmede kararlaştırılan veya hedeflenen süre. | ||
|
Açıklama
Bu öznitelik, Hizmet Seviyesi Anlaşması (SLA) uyarınca hizmet talebinin çözülmesi gereken hedef süreyi belirtir. Hedef süre genellikle biletin önceliğine veya türüne bağlıdır. SLA uyumluluğunu hesaplamak için bu bilgi gereklidir. Gerçek çözüm süresi hedefle karşılaştırılarak SLA’nın karşılanıp karşılanmadığı veya ihlal edilip edilmediği belirlenebilir. Farklı talep türleri, ekipler veya temsilciler genelinde SLA performansını analiz etmek, hizmet yönetiminin temel parçalarından biridir.
Neden önemli?
Her müşteri hizmetleri kuruluşu için temel bir performans göstergesi olan SLA uyumluluğunu ölçmek üzere başlangıç noktası sağlar.
Nereden alınır?
Freshdesk Tickets nesnesinde 'fr_due_by' (ilk yanıt) veya 'due_by' (çözüm) gibi bir alan olarak bulunabilir ya da SLA politikası kurallarına göre hesaplanması gerekebilir.
Örnekler
2023-10-25T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
|
|||
|
SLA ihlal edildi mi
IsSlaBreached
|
Hizmet talebinin çözüm süresinin SLA hedefini aşıp aşmadığını belirten mantıksal değer. | ||
|
Açıklama
Hesaplanan bu öznitelik, her hizmet talebinin SLA uyumluluğunu açıkça gösteren ikili bir değer sunar. Gerçek 'ResolutionTime' değeri 'SlaTargetResolutionTime' ile karşılaştırılarak hesaplanır. Gerçek süre hedefi aşıyorsa değer true olur. Bu öznitelik, SLA uyumluluğu analizini ve Dashboard oluşturmayı kolaylaştırır. SLA hedefini aşan biletleri kolayca sayıp filtreleyebilir, uyumsuzluğun boyutunu hızla belirleyebilir ve temel nedenleri bulmak için bu biletlerin süreç örüntülerini ayrıntılı inceleyebilirsiniz. SLA Uyumluluğu Genel Bakış Dashboardunu ve KPI’ını doğrudan destekler.
Neden önemli?
Hedefini karşılamayan her vaka için açık bir gösterge sunarak SLA uyumluluğu analizini kolaylaştırır ve ihlallerin temel nedenlerini incelemenizi sağlar.
Nereden alınır?
Hesaplanan bir alandır. Gerçek çözüm zaman damgası, 'SlaTargetResolutionTime' veya Freshdesk’teki 'due_by' alanıyla karşılaştırılarak elde edilir.
Örnekler
truefalse
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Verilerin kaynak sistemden en son yenilendiği zamanı gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, Veri Setinin Freshdesk’ten en son alındığı veya güncellendiği tarih ve saati kaydeder. Analiz edilen verilerin ne kadar güncel olduğunu göstererek zamanında ve yerinde iş kararları alınmasına yardımcı olur. Analistler bu bilgiyi, verilerin kapsadığı zaman aralığını anlamak ve mevcut en güncel bilgilerle çalıştıklarını doğrulamak için kullanır. Her Process Mining Dashboardu veya raporu için önemli bir üst veri alanıdır; paydaşların verilerin ne zaman güncellendiğini bilmesini sağlar.
Neden önemli?
Verilerin güncelliğini gösterir ve analizlerle kararların güncel bilgilere dayanmasını sağlar.
Nereden alınır?
Veri alma sırasında oluşturulan ve verilerin çekildiği zaman damgasını içeren bir üst veri alanıdır.
Örnekler
2023-12-01T08:00:00Z
|
|||
|
Temsilci devir sayısı
AgentTransferCount
|
Bir hizmet talebinin bir temsilciden diğerine toplam kaç kez yeniden atandığı. | ||
|
Açıklama
Bu vaka düzeyindeki metrik, bir bilete atanan temsilcinin kaç kez değiştiğini sayar. Her hizmet talebi için 'Ticket Reassigned' etkinliğinin gerçekleşme sayısı hesaplanır. 'Ping pong' olarak da bilinen sık devir teslimler, her devirde bağlamın kaybolmasına ve bunun sonucunda önemli gecikmelere ve olumsuz müşteri deneyimine yol açabilir. Devir sayısını analiz etmek; ilk yönlendirmedeki sorunları, temsilcilerin beceri eksiklerini veya süreç karmaşıklığını belirlemeye yardımcı olur. Verimliliği ve müşteri memnuniyetini artırmak için gereksiz devir teslimleri azaltmak hedeflenir.
Neden önemli?
İç devir teslimlerin sıklığını ölçer. Bu devirler gecikmelere ve müşteri memnuniyetsizliğine yol açabilir; analizleri ilk düzeyde çözüm oranını artırmaya yardımcı olur.
Nereden alınır?
Hesaplanan bir alandır. Her benzersiz hizmet talebi için 'Ticket Reassigned' etkinliklerinin sayısını gösterir.
Örnekler
0132
|
|||
|
Ürün
Product
|
Müşterinin talebinin ilgili olduğu ürün veya hizmet. | ||
|
Açıklama
Bu öznitelik, hizmet talebinin hangi ürün veya hizmet grubuyla ilgili olduğunu belirtir. Biletleri yönlendirme ve raporlama amacıyla sınıflandırmak için Freshdesk’te genellikle özel bir alan olarak yapılandırılır. Kuruluşlar, süreci ürüne göre filtreleyerek belirli ürünlerle ilgili sorunları ortaya çıkarabilir. Örneğin, belirli bir ürünün orantısız sayıda destek bileti oluşturup oluşturmadığı veya yeni bir ürün lansmanının talep sayısında artışa yol açıp açmadığı görülebilir. Bu analiz, ürün geliştirme ve yönetim ekiplerine değerli geri bildirim sağlar.
Neden önemli?
Süreci ürün alanına göre filtreleyerek en çok destek talebi oluşturan veya en uzun çözüm sürelerine sahip ürünleri görmenizi sağlar.
Nereden alınır?
Bu genellikle özel bir alandır. Tam konumu Freshdesk yapılandırmasına bağlıdır; büyük olasılıkla 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ülen bir hizmet talebinin daha sonra yeniden açılıp açılmadığını belirten mantıksal değer. | ||
|
Açıklama
Vaka düzeyindeki bu öznitelik, hizmet talebinin yaşam döngüsünün herhangi bir aşamasında 'Bilet yeniden açıldı' etkinliği gerçekleştiğinde true değerini alır. Yeniden çalışma gerektiren vakaları kolayca belirleyip analiz etmenizi sağlar. Yeniden açılan bilet oranının yüksek olması, ilk çözümün etkili veya eksiksiz olmadığını ve bunun verimsizliğe ve müşteri memnuniyetsizliğine yol açtığını gösterebilir. Analistler, yeniden açılan biletleri filtreleyerek yaygın yeniden açılma nedenlerini, hangi temsilci veya ekiplerde oranın daha yüksek olduğunu ve hangi bilet türlerinin yeniden açılmaya daha yatkın olduğunu inceleyebilir.
Neden önemli?
Yeniden çalışma gerektiren vakaları belirler. Bu, çözüm kalitesini ve süreç verimsizliğini gösteren önemli bir ölçüttür. Bu vakaları analiz etmek, ilk temasta çözüm oranını artırmaya yardımcı olur.
Nereden alınır?
Hesaplanan bir alandır. Bir hizmet talebinde Activity = 'Ticket Reopened' olan bir olay varsa değer true olarak ayarlanır.
Örnekler
truefalse
|
|||
Müşteri hizmetleri etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Destek talebi atandı
|
Bir destek talebinin ilgilenilmesi için belirli bir çalışana veya gruba atanmasını ifade eder. Atanan çalışan ya da grup alanı doldurulduğunda veya değiştirildiğinde bu olay destek talebinin geçmişine açıkça kaydedilir. | ||
|
Neden önemli?
Atamaları izlemek; çalışanların iş yükünü analiz etmek, yönlendirme verimsizliklerini belirlemek ve atama süresine ilişkin KPI’ları ölçmek açısından önemlidir. İşlerin nasıl dağıtıldığını ve işe başlanmadan önce nerelerde gecikme yaşandığını anlamaya yardımcı olur.
Nereden alınır?
Agent veya Group alanlarındaki değişikliklerin zaman damgasıyla kaydedildiği Ticket Activities günlüğünden alınır.
Kaydedin
Bir çalışan veya grup için Assigned to alanı güncellendiğinde kaydedilen olay.
Olay türü
explicit
|
|||
|
Destek talebi çözüldü
|
Çalışanın çözüm sunduğu ve destek talebinin durumunu Resolved olarak değiştirdiği önemli aşamayı ifade eder. Bu durum değişikliği, destek talebinin geçmişine açıkça kaydedilir. | ||
|
Neden önemli?
Bu etkinlik, destek talebindeki aktif çalışmanın sona erdiğini gösterir ve çözüm süresini ölçmenin temelini oluşturur. Çalışan performansını ve genel süreç verimliliğini analiz etmek için önemli bir olaydır.
Nereden alınır?
Resolved durumuna geçişi zaman damgasıyla birlikte kaydeden Ticket Activities günlüğünden alınır.
Kaydedin
Destek talebinin Status alanı Resolved olarak güncellendiğinde kaydedilen olay.
Olay türü
explicit
|
|||
|
Destek talebi kapatıldı
|
Bu, destek talebinin kalıcı olarak kapatıldığını gösteren son etkinliktir. Müşteriden yeni bir yanıt gelmezse sistem, Resolved durumunda belirli bir süre geçtikten sonra talebi genellikle otomatik olarak kapatır. | ||
|
Neden önemli?
Bu etkinlik, hizmet talebi sürecinin kesin olarak sona erdiğini gösterir. Uçtan uca çevrim süresini doğru hesaplamak için son noktayı sağlar.
Nereden alınır?
Closed durumuna geçişi kaydeden Ticket Activities günlüğünden alınır. Bu değişiklik genellikle sistem otomasyonu tarafından tetiklenir.
Kaydedin
Destek talebinin Status alanı Closed olarak güncellendiğinde kaydedilen olay.
Olay türü
explicit
|
|||
|
Destek talebi oluşturuldu
|
Bu, müşteri hizmetleri sürecindeki ilk olaydır ve müşterinin talebinin Freshdesk’e kaydedildiği anı gösterir. E-posta, portal, telefon veya API entegrasyonu üzerinden yeni bir destek talebi oluşturulduğunda bu etkinlik açıkça kaydedilir. | ||
|
Neden önemli?
Bu etkinlik her vakanın başlangıç noktasıdır. Toplam çözüm süresini hesaplamak ve kanal ya da türe göre destek talebi hacmindeki eğilimleri incelemek için gereklidir.
Nereden alınır?
Bu, Freshdesk Ticket Activities günlüğünde açıkça kaydedilen bir olaydır. Yeni bir destek talebi kaydı oluşturulduğunda otomatik olarak oluşur.
Kaydedin
Oluşturulduğu anda destek talebinin etkinlik akışına doğrudan kaydedilir.
Olay türü
explicit
|
|||
|
İlk yanıt gönderildi
|
Destek talebi oluşturulduktan sonra çalışanın müşteriye gönderdiği ilk herkese açık yanıtı belirtir. Freshdesk, SLA takibi için First Response Time ölçümünde bu olayı açıkça kaydeder. | ||
|
Neden önemli?
Müşterilere ne kadar hızlı yanıt verildiğini ve SLA uyumluluğunu ölçmek için önemli bir aşamadır. Bu etkinliğe kadar geçen süreyi analiz ederek müşterilerle ilk iletişimdeki gecikmeleri belirleyebilirsiniz.
Nereden alınır?
Freshdesk’in SLA amacıyla izlediği belirli bir olaydır. Çalışanın eklediği ilk herkese açık yorumun zaman damgasına karşılık gelir.
Kaydedin
Destek talebinin konuşma geçmişindeki çalışanın ilk herkese açık yanıtıyla belirlenir.
Olay türü
explicit
|
|||
|
Dahili not eklendi
|
Bir çalışan, diğer çalışanlarla kurum içinde bilgi paylaşmak için destek talebine özel bir not ekler. Destek talebinin etkinlik akışında kaydedilen bu olay yalnızca çalışanlar tarafından görülebilir. | ||
|
Neden önemli?
Dahili notları izlemek, iş birliği örüntülerini analiz etmeye ve kapsamlı kurum içi görüşme gerektiren sorunları belirlemeye yardımcı olur. Çözümden önce çok sayıda dahili not eklenmesi, sorunun karmaşık olduğuna veya bilgi eksikliği bulunduğuna işaret edebilir.
Nereden alınır?
Destek talebinin konuşma geçmişinde Private Note olarak kaydedilir ve müşteriye gönderilen herkese açık yanıtlardan ayırt edilebilir.
Kaydedin
Bir çalışan Private olarak işaretlenmiş bir not eklediğinde kaydedilen olay.
Olay türü
explicit
|
|||
|
Destek talebi yeniden açıldı
|
Müşteri, durumu Resolved olan bir destek talebine yanıt verdiğinde bu etkinlik gerçekleşir ve durum otomatik olarak Open’a döner. Sistem bu olayı açıkça kaydeder. | ||
|
Neden önemli?
Yeniden açılma oranının yüksek olması, ilk çözümlerin etkili olmadığını ve yeniden çalışmaya, müşteri memnuniyetsizliğine yol açtığını gösterir. Bu etkinliği analiz etmek, Ticket Re-opening Analysis yapmak ve talebin ilk temasta çözülmesini iyileştirmek için önemlidir.
Nereden alınır?
Müşterinin yanıtı, durumu Resolved’dan Open’a otomatik olarak değiştirdiğinde bu olay kaydedilir. Durum değişikliği Ticket Activities günlüğünde yer alır.
Kaydedin
Müşteri etkileşimiyle tetiklenen Resolved durumundan Open durumuna geçiş.
Olay türü
explicit
|
|||
|
Destek talebi yeniden atandı
|
İlk atamadan sonra bir destek talebi başka bir çalışana veya gruba aktarıldığında gerçekleşir. Sahip değişikliği olarak destek talebinin etkinlik günlüğüne açıkça kaydedilir. | ||
|
Neden önemli?
Sık yeniden atamalar veya çalışanlar arasındaki yüksek aktarım oranı, genellikle ilk yönlendirmenin yanlış yapıldığını ya da bilginin ekipler arasında paylaşılmadığını gösterir. Bu analiz, talebin ilk temasta çözülmesini iyileştirme fırsatlarını belirlemeye yardımcı olur.
Nereden alınır?
İlk atamadan sonra Ticket Activities günlüğündeki Agent veya Group alanı değişiklikleri izlenerek kaydedilir.
Kaydedin
İlk atama yapıldıktan sonra Assigned to alanında yapılan sonraki bir güncelleme.
Olay türü
explicit
|
|||
|
Destek talebinin önceliği değiştirildi
|
Bir çalışan veya otomasyon kuralı, destek talebinin öncelik düzeyini Low’dan High’a değiştirdiğinde bu olay gerçekleşir. Değişiklik, destek talebinin etkinlik günlüğüne açıkça kaydedilir. | ||
|
Neden önemli?
Öncelik değişiklikleri, konunun üst kademeye aktarıldığını veya aciliyetinin yeniden değerlendirildiğini gösterebilir. Bu değişiklikleri analiz ederek aktarımlara yol açan etkenleri ve bunların çözüm süresine etkisini anlayabilirsiniz.
Nereden alınır?
Priority alanı dahil olmak üzere destek talebi özelliklerindeki tüm değişiklikleri kaydeden Ticket Activities günlüğünden alınır.
Kaydedin
Priority alanının değeri güncellendiğinde kaydedilen olay.
Olay türü
explicit
|
|||
|
Durum beklemede olarak değiştirildi
|
Çalışan müşteriden bilgi beklediğinde destek talebinin durumunu Pending olarak değiştirir. Bu olay, destek talebinin etkinlik geçmişine durum değişikliği olarak açıkça kaydedilir. | ||
|
Neden önemli?
Sürecin dışarıdan bilgi beklerken durakladığı dönemleri gösterir. Bu durumda geçen süreyi analiz etmek, müşteriden kaynaklanan gecikmeleri ölçmeye ve SLA uyumluluğunu incelemeye yardımcı olur; SLA sayaçları genellikle bu durumda duraklatılır.
Nereden alınır?
Pending durumuna geçiş de dahil olmak üzere tüm durum değişikliklerini kaydeden Ticket Activities günlüğünden alınır.
Kaydedin
Destek talebinin Status alanı Pending olarak güncellendiğinde kaydedilen olay.
Olay türü
explicit
|
|||
|
Memnuniyet anketi gönderildi
|
Genellikle destek talebi çözüldükten sonra bir otomasyon kuralıyla gönderilen müşteri memnuniyeti anketini ifade eder. Otomasyon işlemi destek talebinin geçmişine kaydediliyorsa bu olay da yakalanabilir. | ||
|
Neden önemli?
Geri bildirim toplama sürecinin başlangıcını gösterir. Anket yanıtlarını süreç varyantlarıyla ilişkilendirmek, süreç performansının müşteri memnuniyetini nasıl etkilediğine dair önemli içgörüler sağlayabilir.
Nereden alınır?
Bu işlem genellikle bir Automation Rule tarafından tetiklenir. Ayrı bir olay olarak destek talebinin etkinlik günlüğünde görünmesi, Freshdesk’in otomasyon kayıt ayarlarına bağlıdır.
Kaydedin
Destek talebi çözüldükten sonra otomasyon kuralı çalıştırıldığında kaydedilen olay.
Olay türü
explicit
|
|||
|
Müşteri yanıt verdi
|
Müşteriden gelen yeni bir yanıtı veya iletişimi ifade eder. Destek talebinin konuşma akışında açıkça kaydedilen bu olay, genellikle durumun Pending’den Open’a değişmesini sağlar. | ||
|
Neden önemli?
Bu etkinlik, müşteri iletişimindeki karşılıklı yazışmaları anlamak ve müşterinin yanıt süresini ölçmek açısından önemlidir. Ayrıca duraklatılmış SLA sayaçlarını yeniden başlatarak uyumluluk metriklerini etkiler.
Nereden alınır?
Destek talebinin konuşma akışına yeni bir kayıt olarak eklenir. Olay, müşterinin kişi kaydıyla ilişkilendirilir.
Kaydedin
Müşteri kişisinin destek talebine eklediği yeni bir herkese açık not.
Olay türü
explicit
|
|||
|
SLA ihlal edildi
|
Bir destek talebine yanıt verme veya talebi çözme süresi, tanımlı SLA hedefini aştığında gerçekleşen hesaplanmış bir olaydır. Freshdesk, SLA durumunu izler ve destek taleplerini violated olarak işaretler; bu bilgi, ilgili etkinliği belirlemek için kullanılabilir. | ||
|
Neden önemli?
Bu etkinlik, hizmet seviyesi taahhütlerinin nerede ve ne zaman karşılanmadığını göstererek SLA uyumluluğu analizini destekler. Gecikmelerin sistemik nedenlerini belirlemek için önemlidir.
Nereden alınır?
Bu olay, destek talebinin SLA durumu izlenerek çıkarılır veya hesaplanır. SLA durumu Violated olarak değiştiğinde bir etkinlik oluşturulabilir ya da yanıt ve çözüm zaman damgaları SLA hedefleriyle karşılaştırılabilir.
Kaydedin
Time to Resolve, SLA Target Resolution Time değerini aştığında destek talebi verilerinden belirlenir.
Olay türü
calculated
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Süreçlerinizi net biçimde anlayarak müşteri hizmetleri operasyonlarınızı dönüştürmeye başlayın. Bu şablon, veriye dayalı iyileştirme yolundaki ilk adımınız.
Freshdesk müşteri hizmetlerinizi bugün iyileştirin
İlk temasta çözüm oranını %80’e çıkarın, müşterilerinizi memnun edin.
Kredi kartı gerekmez, kurulum dakikalar içinde tamamlanır