Müşteri Hizmetleri Veri Şablonunuz
Müşteri Hizmetleri Veri Şablonunuz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Microsoft Dynamics 365 Müşteri Hizmetleri için veri çıkarma rehberi
Müşteri hizmetleri öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Hizmet talebi
ServiceRequest
|
Vaka veya bilet olarak da adlandırılan müşteri hizmetleri talebinin benzersiz tanımlayıcısıdır. | ||
|
Açıklama
Hizmet Talebi, tek bir müşteri sorusu veya sorunuyla ilgili tüm aktiviteleri birbirine bağlayan birincil tanımlayıcıdır. Process Mining için Vaka Kimliği görevi görür ve her müşteri etkileşiminin oluşturulmasından kapanışına kadar eksiksiz ve tutarlı biçimde izlenmesini sağlar. Hizmet Talebi bazında analiz yapmak, uçtan uca yolculuğu izlemeye, çözüm sürelerini ölçmeye ve benzer vakalardaki örüntüleri belirlemeye imkan verir.
Neden önemli?
Bu, ilgili tüm olayları tek bir süreç örneğinde birleştiren ve uçtan uca süreç analizini mümkün kılan temel Vaka Kimliğidir.
Nereden alınır?
Bu, Microsoft Dynamics 365 Customer Service içindeki Vaka (incident) varlığının birincil anahtarıdır.
Örnekler
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
|
|||
|
Aktivite
ActivityName
|
Bir hizmet talebi için belirli bir zamanda gerçekleşen iş olayının adıdır. | ||
|
Açıklama
Bu öznitelik, müşteri hizmetleri sürecindeki tek bir adımı veya durum değişikliğini açıklar. Örneğin 'Vaka Oluşturuldu', 'Temsilci Sorunu İnceledi' veya 'Vaka Çözümlendi'. Bu aktiviteler, süreç akışını görselleştirip analiz etmenizi sağlayan süreç haritasının temelini oluşturur. Her aktivite, bir zaman damgasıyla birleştirildiğinde süreç sırasını tanımlayan bir olay oluşturur.
Neden önemli?
Aktiviteler süreçteki adımları tanımlar. Aktivitelerin sırasını ve sıklığını analiz etmek, süreç akışlarını anlamak, sapmaları belirlemek ve darboğazları bulmak için temel bir adımdır.
Nereden alınır?
Genellikle statuscode durum değişiklikleri veya Task, E-posta ya da Telefon Araması gibi ilişkili varlıklardaki belirli olaylar standart bir aktivite adına haritalanarak elde edilir.
Örnekler
Kayıt oluşturulduTemsilci sorunu incelediMüşteriye çözüm önerildiVaka kapatıldı
|
|||
|
Başlangıç zamanı
EventTime
|
Aktivitenin gerçekleştiği zamanı gösteren zaman damgasıdır. | ||
|
Açıklama
Bu öznitelik, belirli bir aktivitenin gerçekleştiği kesin tarih ve saati kaydeder. Olayları doğru sıraya koymak ve çevrim süreleri, süreler ile aktiviteler arasındaki bekleme süreleri dahil olmak üzere zamana dayalı tüm analizleri yapmak için gereklidir. Doğru ve tutarlı bir zaman damgası, Process Mining analizinin güvenilirliği açısından büyük önem taşır.
Neden önemli?
Bu zaman damgası olayları kronolojik olarak sıralar ve performans analizi ile darboğazların belirlenmesi için gerekli olan tüm süre hesaplamalarını mümkün kılar.
Nereden alınır?
Bu, Vaka (incident) varlığındaki veya ilişkili aktivite varlıklarındaki, örneğin E-posta, Task ve Telefon Araması, 'createdon' ya da 'modifiedon' gibi alanlara karşılık gelir.
Örnekler
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
|
|||
|
Kaynak sistem
SourceSystem
|
Verilerin hangi kaynak sistemden çıkarıldığını belirtir. | ||
|
Açıklama
Bu öznitelik, olay verilerinin kaynağını belirtir. Bu süreçte kaynak olarak sürekli Microsoft Dynamics 365 Customer Service gösterilir. Birden fazla sistemin bulunduğu ortamlarda bu alan, veri kaynaklarını ayırt etmek ve veri soy ağını korumak için önemlidir.
Neden önemli?
Veri yönetişimi ve özellikle birden fazla sistemin birleştirildiği analizlerde veri tutarsızlıklarını gidermek için gerekli olan açık bir veri soy ağını sağlar.
Nereden alınır?
Bu, genellikle veri çıkarma ve dönüştürme sırasında veri setinin kaynağını belirtmek için eklenen statik bir değerdir.
Örnekler
Microsoft Dynamics 365 Customer Service
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Kaynak sistemden yapılan son veri yenilemesinin veya çıkarımının zaman damgasıdır. | ||
|
Açıklama
Bu öznitelik, verilerin Microsoft Dynamics 365'ten en son ne zaman alındığını gösterir. Analiz edilen verilerin güncelliğini anlamak için kullanılır ve raporlama ile izleme açısından gereklidir. Kullanıcıların Dashboard ve analizleri yorumlarken verilerin güncelliğini bilmesini sağlar.
Neden önemli?
Verilerin ne kadar güncel olduğu hakkında bilgi verir. Bu bilgi, süreç analizine dayalı zamanında ve doğru iş kararları almak için önemlidir.
Nereden alınır?
Bu değer, veri çıkarımı sırasında oluşturulur ve veri setine zaman damgasıyla eklenir.
Örnekler
2023-10-27T08:00:00Z
|
|||
|
Durum nedeni
StatusReason
|
Hizmet talebinin mevcut durumuna ilişkin daha ayrıntılı bir neden sağlar. | ||
|
Açıklama
Bir vaka 'Etkin' veya 'Çözümlendi' gibi genel bir duruma sahipken Durum Nedeni, 'Bilgi sağlandı' veya 'Sorun çözüldü' gibi daha özel bir bağlam sunar. Bu öznitelik, vakaların yaşam döngüsü boyunca nasıl ve neden ilerlediğini anlamak için önemlidir. Örneğin, başarıyla çözümlenen vakalarla müşteri tarafından iptal edilen vakaları ayırt edebilir. Bu ayrım, sonuçların doğru analiz edilmesi için gereklidir.
Neden önemli?
Bir vakanın sonucuna ve durum değişikliklerinin nedenlerine ilişkin ayrıntılı içgörüler sunar. Böylece çözüm yolları ve kök nedenler daha hassas biçimde analiz edilebilir.
Nereden alınır?
Vaka (incident) varlığındaki 'Status Reason' (statuscode) alanına karşılık gelir.
Örnekler
Devam EdiyorBeklemedeSorun ÇözüldüBilgi Sağlandı
|
|||
|
Hizmet talebi türü
ServiceRequestType
|
Hizmet talebinin birincil kategorisi veya sınıflandırmasıdır. | ||
|
Açıklama
Bu öznitelik, hizmet talebini niteliğine göre, örneğin 'Faturalama sorusu', 'Teknik destek' veya 'Ürün geri bildirimi' olarak kategorilere ayırır. Farklı talep türlerinin nasıl ele alındığını anlamak için süreç analizini bölümlere ayırmanın temelini oluşturur. Tür bazında analiz, bazı kategorilerin daha uzun çözüm sürelerine veya daha yüksek eskalasyon oranlarına sahip olduğunu ya da farklı süreç yollarını izlediğini gösterebilir.
Neden önemli?
Türe özgü darboğazları, kaynak ihtiyaçlarını ve iyileştirme fırsatlarını ortaya çıkarmak için süreç segmentasyonu sağlar. Böylece daha iyi yönlendirme ve ele alma stratejileri geliştirilebilir.
Nereden alınır?
Bu bilgi genellikle Vaka (incident) varlığındaki 'Subject' (subjectid) alanında veya özel bir kategori alanında saklanır.
Örnekler
Faturalandırma TalebiTeknik DestekÜrün Geri BildirimiHesap Yönetimi
|
|||
|
Kanal
Channel
|
Hizmet talebinin başlatıldığı iletişim kanalıdır. | ||
|
Açıklama
Bu öznitelik, müşteri etkileşiminin kaynağını Phone, E-posta, Web Portal veya Chat gibi değerlerle belirler. Farklı kanalların süreç akışları, müşteri beklentileri ve çözüm karmaşıklıkları genellikle birbirinden farklıdır. Süreci kanallara göre analiz etmek, kanala özel iş akışlarını ve kaynak dağılımını optimize etmenize yardımcı olur.
Neden önemli?
Farklı müşteri iletişim kanallarının süreç verimliliğini, çözüm süresini ve müşteri memnuniyetini nasıl etkilediğine dair içgörüler sağlar.
Nereden alınır?
Vaka (incident) varlığındaki 'Case Origin' (caseorigincode) alanına karşılık gelir.
Örnekler
TelefonE-postaWebChat
|
|||
|
Müşteri adı
CustomerName
|
Hizmet talebiyle ilişkili müşterinin veya hesabın adıdır. | ||
|
Açıklama
Bu öznitelik, hizmet talebini başlatan müşteriyi tanımlar. Süreci müşteri odaklı bir bakışla analiz etmenizi sağlar ve en çok talebi gönderen, en uzun çözüm sürelerini yaşayan veya en karmaşık sorunlara sahip müşterileri belirlemenize yardımcı olur. Müşteri ilişkilerini yönetmek ve müşteriye özel hizmet sunumunu iyileştirmek için gereklidir.
Neden önemli?
Müşteri düzeyinde analiz yapmanızı, örüntüleri belirlemenizi, önemli hesaplara sunulan hizmeti iyileştirmenizi ve müşteri yolculuğunu anlamanızı sağlar.
Nereden alınır?
Vaka (incident) varlığındaki 'Customer' (customerid) arama alanıdır ve bir Account veya Contact kaydına işaret edebilir.
Örnekler
Global Tech Inc.Jane DoeInnovate Solutions
|
|||
|
Öncelik
Priority
|
Hizmet talebine atanan ve aciliyetini gösteren öncelik düzeyidir. | ||
|
Açıklama
Bu öznitelik, hizmet talebinin aciliyetini tanımlar ve genellikle Düşük, Normal, Yüksek veya Acil olarak sınıflandırılır. Öncelik, vakaların ele alınma sırasını belirlemek için kullanılır ve çoğu zaman SLA hedeflerini belirler. Önceliğin süreç akışını, kaynak tahsisini ve çözüm sürelerini nasıl etkilediğini analiz etmek, önemli sorunların zamanında ele alınmasını sağlamak için gereklidir.
Neden önemli?
Yüksek öncelikli taleplerin daha hızlı işlenip hedeflerini karşılayıp karşılamadığını ve öncelik düzeylerinin genel süreç performansını nasıl etkilediğini anlamaya yardımcı olur.
Nereden alınır?
Vaka (incident) varlığındaki 'Priority' (prioritycode) alanına karşılık gelir.
Örnekler
DüşükNormalYüksek
|
|||
|
SLA hedef çözüm süresi
SlaTargetResolutionTime
|
Hizmet talebinin çözümü için sözleşmeyle kararlaştırılan hedef süredir. | ||
|
Açıklama
Bu öznitelik, etkin Hizmet Düzeyi Anlaşmasına (SLA) göre bir hizmet talebinin çözülmesi gereken hedef süreyi belirtir. Gerçek performansın ölçüldüğü temel değeri oluşturur. Bu değer, SLA Uyumluluk İzleme Dashboardu ve SLA Uyumluluk Oranı KPI hesaplaması için önemlidir; sürecin hizmet taahhütlerini karşılayamadığı noktaları gösterir.
Neden önemli?
Hizmet performansını taahhütlerle karşılaştırmak için kullanılan temel referanstır ve SLA uyumluluğu ile ihlallerinin doğrudan analiz edilmesini sağlar.
Nereden alınır?
Bu değer, Dynamics 365 içindeki SLA yapılandırmasıyla belirlenir ve SLA KPI Örnekleri aracılığıyla bir vakayla ilişkilendirilir.
Örnekler
2592008640014400
|
|||
|
Temsilci adı
AgentName
|
Aktiviteden sorumlu müşteri hizmetleri temsilcisinin veya kullanıcının adıdır. | ||
|
Açıklama
Bu öznitelik, kuyruktan bir öğe alan veya vakayı çözen belirli temsilciyi ya da sistem kullanıcısını tanımlar. Temsilci performansını, iş yükü dağılımını ve kaynak tahsisini analiz etmek için gereklidir. Kuruluşlar aktiviteleri temsilci düzeyinde izleyerek yüksek performans gösterenleri, eğitim ihtiyaçlarını ve iş yükü dengesizliklerini belirleyebilir.
Neden önemli?
Bireysel ve ekip performansını analiz etmenizi, iş yükünü dengelemenizi ve genel hizmet kalitesini iyileştirecek koçluk fırsatlarını belirlemenizi sağlar.
Nereden alınır?
Vaka (incident) varlığındaki ve System User (systemuser) varlığına bağlanan 'Owner' (ownerid) alanına karşılık gelir.
Örnekler
Alice SmithBob JohnsonSistem
|
|||
|
Bilgi makalesi kimliği
KnowledgeArticleId
|
Hizmet talebine bağlanan bilgi bankası makalesinin tanımlayıcısıdır. | ||
|
Açıklama
Bu öznitelik, bir hizmet talebinin çözümü sırasında kullanılan veya ilişkilendirilen bilgi makalesinin kimliğini içerir. Temsilcilerin müşteri sorunlarını çözmek için bilgi tabanından ne kadar etkili yararlandığını doğrudan ölçmenizi sağlar. Bu veri, Bilgi Makalesi Kullanımı Dashboardu ve ilgili KPI için önemlidir; bilgi tabanının değerini ve kapsamını değerlendirmenize yardımcı olur.
Neden önemli?
Bilgi bankası kullanımını izler ve temsilcilerin sorunları daha hızlı ve tutarlı biçimde çözmek için mevcut kaynaklardan yararlanıp yararlanmadığını anlamaya yardımcı olur.
Nereden alınır?
Bu bilgi, Vaka (incident) ile Bilgi Makalesi (knowledgearticle) varlıkları arasındaki ilişkide bulunur.
Örnekler
KA-01337KA-02048
|
|||
|
CSAT puanı
CustomerSatisfactionScore
|
Vaka çözümlendikten sonra müşteri tarafından verilen memnuniyet puanıdır. | ||
|
Açıklama
Bu öznitelik, genellikle bir hizmet talebi kapatıldıktan sonra toplanan müşteri memnuniyeti (CSAT) anketindeki sayısal veya kategorik puanı içerir. Hizmet kalitesinin müşteri tarafından nasıl algılandığını doğrudan ölçer. Bu veri, Müşteri Memnuniyeti Eğilimleri Dashboardu ve Çözüm Sonrası Ortalama CSAT Skoru KPI için gereklidir; süreç performansını müşteri sonuçlarıyla ilişkilendirir.
Neden önemli?
Müşteri memnuniyetini doğrudan ölçer ve kuruluşun süreç davranışlarını müşteri algısıyla ilişkilendirerek iyileştirmeler yapmasını sağlar.
Nereden alınır?
Genellikle Customer Voice gibi ilişkili bir anket varlığından alınır ve Vaka (incident) varlığına bağlanır.
Örnekler
5341
|
|||
|
Eskalasyon yapıldı mı
IsEscalated
|
Hizmet talebinin eskale edilip edilmediğini gösteren işarettir. | ||
|
Açıklama
Bu boolean öznitelik, bir hizmet talebinin üst seviyeye aktarılıp aktarılmadığını gösterir. Üst seviyeye aktarma, birinci seviye desteğin sorunu çözememesi ve daha kıdemli bir ekibin veya uzmanın müdahalesinin gerekmesi durumunda gerçekleşir. Bu işareti izlemek, üst seviyeye aktarmaların temel nedenlerini ve ilk destek katmanlarındaki zayıflıkları belirlemek için gereklidir. Ayrıca İç Üst Seviyeye Aktarma Yolları Dashboardu ve İç Üst Seviyeye Aktarma Oranı KPI için kullanılır.
Neden önemli?
Eskalasyonların sıklığını doğrudan ölçer, ilk temasta çözümle ilgili sorunları gösterir ve süreçte ya da temsilci becerilerinde iyileştirme gereken alanlara işaret eder.
Nereden alınır?
Vaka (incident) varlığındaki 'Is Escalated' (isescalated) alanına karşılık gelir.
Örnekler
truefalse
|
|||
|
İlgili ürün
ProductInvolved
|
Müşterinin hizmet talebiyle ilişkili üründür. | ||
|
Açıklama
Bu öznitelik, müşterinin sorununun ilgili olduğu belirli ürünü veya hizmeti tanımlar. Hizmet sürecini ürün bazında bölümlere ayırmanızı sağlar ve bazı ürünlerin daha fazla destek talebi veya daha karmaşık sorun oluşturup oluşturmadığını ya da özel temsilci becerileri gerektirip gerektirmediğini gösterebilir. Bu analiz, ürün iyileştirme ve kaynak planlamasına yardımcı olur.
Neden önemli?
Ürüne özel süreç analizi yapmanızı, tekrarlanan ürün sorunlarını belirlemenizi, destek belgelerini iyileştirmenizi ve uzman kaynakları etkili biçimde tahsis etmenizi sağlar.
Nereden alınır?
Vaka (incident) varlığındaki 'Product' (productid) arama alanına karşılık gelir.
Örnekler
Alpha-100 YazıcıZeta CRM YazılımıOmega Veri Planı
|
|||
|
İlk temasta çözüldü mü
IsFirstContactResolution
|
Talebin ilk temas sırasında çözülüp çözülmediğini gösteren işarettir. | ||
|
Açıklama
Bu hesaplanmış öznitelik, müşteriyle ek bir etkileşim olmadan veya temsilcinin yeniden atanmasını gerektiren önemli gecikmeler yaşanmadan çözülen hizmet taleplerini belirler. Kesin mantığı tanımlamak karmaşık olabilir, ancak genellikle kısa bir çevrim süresinin ve ilk etkileşimden sonra yeniden açma ya da müşteri sorusu aktivitelerinin bulunmadığının kontrol edilmesini içerir. İlk Temasta Çözüm Oranı KPI'ının temelini oluşturur.
Neden önemli?
Bu, hizmet verimliliğinin ve müşteri memnuniyetinin önemli bir ölçüsüdür; sorunları hızlı ve eksiksiz çözme becerisini gösterir.
Nereden alınır?
Her vaka için olay günlüğündeki aktivitelerin sırasına ve zamanlamasına göre hesaplanır.
Örnekler
truefalse
|
|||
|
Sahip ekip
OwnerTeam
|
Hizmet talebinin mevcut sahibi olan ekiptir. | ||
|
Açıklama
Bu öznitelik, hizmet talebinden sorumlu ekibi tanımlar. Bir talebin sahibi bireysel bir temsilci veya ekip, yani kuyruk, olabilir. Ekip bazında analiz yapmak, ekip performansını, farklı destek seviyeleri veya uzmanlıklar arasındaki iş yükü dağılımını anlamak ve ekipler arasındaki süreç farklılıklarını belirlemek için gereklidir.
Neden önemli?
Ekip düzeyinde performans analizi yapmanızı sağlar. Bu, destek seviyelerini ve uzman ekipleri etkili biçimde yönetmek için gereklidir.
Nereden alınır?
Vaka (incident) varlığındaki 'Owner' (ownerid) alanından türetilir. Sahip, System User yerine bir Team kaydı olduğunda kullanılır.
Örnekler
1. Kademe DestekFaturalandırma DepartmanıTeknik Uzmanlar
|
|||
|
SLA ihlal edildi mi
IsSlaBreached
|
Hizmet talebinin SLA hedefini aşıp aşmadığını gösteren hesaplanmış işarettir. | ||
|
Açıklama
Bu boolean işareti, bir hizmet talebinin gerçek çözüm süresi ile SLA Hedef Çözüm Süresinin karşılaştırılmasıyla belirlenir. Gerçek süre hedef süreden uzunsa değer true olarak ayarlanır. Bu öznitelik, SLA Uyumluluk İzleme Dashboardu ve SLA Uyumluluk Oranı KPI hesaplaması için temel oluşturur ve her vakanın SLA performansını ikili bir sonuç olarak gösterir.
Neden önemli?
Her vakada SLA'ya uyum için net bir başarı veya başarısızlık sonucu sağlar. Böylece ihlallerin kök nedenlerini filtrelemek, toplulaştırmak ve analiz etmek kolaylaşır.
Nereden alınır?
'ServiceRequestCycleTime' ile 'SlaTargetResolutionTime' karşılaştırılarak hesaplanır.
Örnekler
truefalse
|
|||
|
Yeniden çalışma yapıldı mı
IsRework
|
Bir vakada yeniden çalışma aktiviteleri bulunup bulunmadığını gösteren hesaplanmış işarettir. | ||
|
Açıklama
Bu boolean işareti, bir vakanın yeniden çalışma döngüleri veya tekrarlanan etkinlikler içerip içermediğini gösterir. Örneğin birden fazla 'Müşteriden Bilgi İstendi' etkinliği ya da vaka çözüldükten sonra gerçekleşen 'Vaka Yeniden Etkinleştirildi' etkinliği bu kapsamdadır. Değer, verimsizliğe veya sorunun ilk seferde doğru çözülememesine işaret eden örüntüler için etkinlik dizisinin analiz edilmesiyle hesaplanır. Bu öznitelik, Yeniden Çalışma ve Tekrarlanan İletişim Analizi Dashboardu için önemlidir.
Neden önemli?
Süreç verimsizliklerini ölçüp ayrıştırmaya yardımcı olur ve analistlerin tekrarlanan işlerin ve boşa harcanan çabanın kök nedenlerine odaklanmasını sağlar.
Nereden alınır?
Process Mining analitiği kullanılarak belirli aktivite sıraları, örneğin Çözümlendi -> Yeniden Etkinleştirildi, veya bir vaka içindeki tekrarlanan aktiviteler tespit edilerek hesaplanır.
Örnekler
truefalse
|
|||
Müşteri hizmetleri aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Kayıt atandı
|
Bu etkinlik, bir kaydın işlenmek üzere belirli bir kuyruğa veya kullanıcıya atanmasını ifade eder. Sistem, kayıt sahibindeki değişiklikleri açıkça kaydeder ve bu değişiklikler sistemin denetim günlükleri üzerinden izlenebilir. | ||
|
Neden önemli?
Atamaları izlemek, iş yükü dağılımını analiz etmek, atamayla ilişkili gecikmeleri belirlemek ve yönlendirme verimliliğini anlamak için önemlidir. Kayıtların doğru ekibe veya kişiye ne kadar hızlı yönlendirildiğiyle ilgili soruların yanıtlanmasına yardımcı olur.
Nereden alınır?
'Incident' varlığındaki 'ownerid' alanında yapılan değişiklikler izlenerek yakalanır. Değişikliğin zaman damgası denetim geçmişi günlüklerinde bulunur.
Yakalayın
Denetim günlüklerinden 'ownerid' alanındaki zaman damgalı değişiklikleri çıkarın.
Olay türü
explicit
|
|||
|
Kayıt eskale edildi
|
Bir kaydın daha üst bir destek seviyesine veya farklı bir ekibe resmi olarak eskale edilmesini ifade eder. Bu, kaydı belirlenmiş bir eskalasyon kuyruğuna veya kullanıcıya yeniden atayan açık bir kullanıcı işlemi olabilir. | ||
|
Neden önemli?
Eskale edilen vakaları izlemek, 'Dahili Eskalasyon Oranı' KPI'ı ve birinci seviye desteğin çözemediği sorunların kök nedenlerini belirlemek için büyük önem taşır. Bu izleme, süreçteki zayıf noktaları ve eğitim fırsatlarını ortaya çıkarır.
Nereden alınır?
'ownerid' alanının belirlenmiş bir eskalasyon kuyruğuna veya ekibine değiştirilmesinden çıkarılır. Vakanın eskale edildiğini işaretleyen açık bir özel işlem de olabilir.
Yakalayın
'ownerid' alanının bilinen bir eskalasyon kuyruğuna değiştirildiği zaman damgalı olayı belirleyin.
Olay türü
inferred
|
|||
|
Kayıt oluşturuldu
|
Bu etkinlik, sistemde yeni bir kayıt oluşturulduğunda müşteri hizmetleri sürecinin başlangıcını gösterir. Oluşturma işlemi, 'Incident' varlık kaydı ilk kez kaydedildiğinde belirli bir zaman damgasıyla günlüğe yazılan açık bir olaydır. | ||
|
Neden önemli?
Birincil başlangıç olayı olarak bu etkinlik, genel kayıt yaşam döngüsü süresini hesaplamak ve kayıt hacmi eğilimlerini anlamak için gereklidir. Sonraki tüm süreç analizleri için referans noktası oluşturur.
Nereden alınır?
Bu olay, her yeni kayıt için 'Incident' (Case) varlığındaki 'createdon' zaman damgasından alınır.
Yakalayın
Incident kaydının 'createdon' zaman damgasını kullanın.
Olay türü
explicit
|
|||
|
SLA zamanlayıcısı başlatıldı
|
Kayıt için bir Hizmet Seviyesi Anlaşması (SLA) zamanlayıcısının etkinleştirildiğini gösterir. Zamanlayıcı, 'İlk Yanıt Tarihi' veya 'Çözüm Tarihi' gibi tanımlı bir hizmet metriğine göre süreyi izlemeye başlar. Bu, Dynamics 365 SLA motoru tarafından yönetilen açık bir olaydır. | ||
|
Neden önemli?
Bu etkinlik, SLA uyumluluğunu izlemek ve hizmet taahhütleri için sürenin ne zaman başladığını anlamak açısından temel öneme sahiptir. Hizmet hedeflerine ulaşılıp ulaşılmadığının analizini doğrudan destekler.
Nereden alınır?
'Incident' varlığıyla ilişkili 'SLA KPI Instance' varlığında günlüğe yazılır. İlgili SLA KPI Instance kaydının 'createdon' zaman damgası başlangıcı gösterir.
Yakalayın
Kayıtla ilişkili 'SLA KPI Instance' kaydının oluşturulma zaman damgasını kullanın.
Olay türü
explicit
|
|||
|
Vaka çözümlendi
|
Bu, temsilcinin müşterinin sorununu giderilmiş kabul ettiği noktayı gösteren önemli bir kilometre taşıdır. Dynamics 365 içindeki açık bir işlemle oluşturulur ve vakayla bağlantılı bir 'Vaka Çözümü' aktivite kaydı yaratır. | ||
|
Neden önemli?
Başarıya dayalı birincil bitiş olayı olarak bu aktivite, çözüm sürelerini ve başarı oranlarını hesaplamak için gereklidir. Neredeyse tüm müşteri hizmetleri KPI'larının temel bileşenlerinden biridir.
Nereden alınır?
Bu olay, bir 'Çözüm' (Vaka Çözümü) aktivite kaydının oluşturulmasına karşılık gelir. Bu kayıttaki 'actualend' zaman damgası çözüm zamanını gösterir.
Yakalayın
İlişkili 'Çözüm' aktivite kaydındaki 'actualend' veya 'createdon' zaman damgasını kullanın.
Olay türü
explicit
|
|||
|
Vaka kapatıldı
|
Bu, vaka kaydının nihai idari kapanışıdır ve çözümle aynı anda veya daha sonra gerçekleşebilir. Bu aktivite, vakanın durumunun 'Kapalı' olarak değiştirilmesiyle kaydedilir. | ||
|
Neden önemli?
Bu olay, sistemdeki süreç yaşam döngüsünün kesin sonunu gösterir. 'Çözümlendi' ile 'Kapalı' arasındaki süre, idari iş yükünü veya kayıtların sonlandırılmasındaki gecikmeleri gösterebilir.
Nereden alınır?
'Incident' varlığındaki 'statecode' alanının 'İptal Edildi' (2) veya özel bir kapalı duruma değiştirilmesiyle kaydedilir. Zaman damgası denetim geçmişinde bulunur.
Yakalayın
'statecode' alanının nihai terminal duruma, örneğin İptal Edildi veya Kapalı durumuna, değiştiği zaman damgasını izleyin.
Olay türü
explicit
|
|||
|
Kayıt kategorisi değiştirildi
|
Bu olay, bir temsilcinin kaydın ilk oluşturulmasından sonra kategorisini veya konusunu değiştirmesiyle gerçekleşir. Bu, sistemin denetim işlevi tarafından izlenen açık bir değişikliktir. | ||
|
Neden önemli?
Yeniden kategorilendirmeyi izlemek, 'Hizmet Talebi Yeniden Kategorilendirme Oranı' KPI'ı için önemlidir. Yüksek sıklık, ilk triyajda sorunlar olduğunu ve bunun yanlış yönlendirmeye ve gecikmelere yol açtığını gösterir.
Nereden alınır?
'Incident' varlığının denetim geçmişinden alınır. Özellikle 'subjectid' alanındaki veya diğer özel kategorilendirme alanlarındaki değişiklikler izlenir.
Yakalayın
Denetim günlüklerinden 'subjectid' alanındaki zaman damgalı değişiklikleri çıkarın.
Olay türü
explicit
|
|||
|
Kuyruk öğesi temsilci tarafından alındı
|
Bu olay, bir temsilcinin üzerinde çalışmaya başlamak için paylaşılan kuyruktan bir kaydı etkin biçimde almasıyla gerçekleşir. Bu, kullanıcının bilinçli olarak yaptığı bir işlemdir ve sistemin kaydı kuyruğa atamasından farklıdır. | ||
|
Neden önemli?
Bu etkinlik, bir kaydın temsilci çalışmaya başlamadan önce kuyrukta ne kadar beklediğini ölçmeye yardımcı olur. Kuyruk darboğazlarını belirlemek ve temsilcilerin proaktifliğini anlamak için önemlidir.
Nereden alınır?
Kayıtla ilişkili 'QueueItem' varlığındaki 'workedbyid' alanı bir kullanıcı tarafından güncellendiğinde veya kayıt sahibi kuyruktan kullanıcıya değiştiğinde izlenir.
Yakalayın
QueueItem içindeki 'workedbyid' alanının doldurulduğu zaman damgasını belirleyin.
Olay türü
explicit
|
|||
|
Memnuniyet anketi gönderildi
|
Genellikle bir vaka çözümlendikten sonra otomatik olarak tetiklenen müşteri memnuniyeti anketinin gönderilmesini gösterir. Bu olay çoğunlukla giden bir e-posta veya Customer Voice anket aktivitesi olarak kaydedilir. | ||
|
Neden önemli?
Bu aktivite, operasyonel süreci müşteri deneyimi sonuçlarıyla ilişkilendirir. Vakanın izlediği süreç yolunu dikkate alarak memnuniyet puanlarını analiz etmenizi sağlar.
Nereden alınır?
Anket bağlantısı içeren giden bir 'E-posta' aktivitesinin oluşturulmasından veya vakayla ilişkili bir 'Customer Voice anket daveti' aktivite kaydından çıkarılır.
Yakalayın
Anketle ilişkili aktivite kaydının oluşturulma zaman damgasını kullanın.
Olay türü
inferred
|
|||
|
Müşteriden bilgi istendi
|
Bu etkinlik, temsilcinin ilerlemek için müşteriden daha fazla bilgiye ihtiyaç duyduğu noktayı gösterir. Genellikle kayıt durumunun 'beklemede' durumuna değiştirilmesiyle veya kayıt zaman çizelgesinden giden bir e-posta gönderilmesiyle çıkarımsal olarak belirlenir. | ||
|
Neden önemli?
Bu etkinlik, müşteriden kaynaklanan gecikmeleri ölçmek ve 'Müşteri Bilgisi Bekleme Süresi' KPI'ını anlamak için önemlidir. Sürecin dış girdiyi bekleyerek geçen bölümünü ayırmaya yardımcı olur.
Nereden alınır?
'Incident' varlığındaki 'statuscode' alanının 'Müşteri Bekleniyor' gerekçesiyle 'Beklemede' gibi bir değere değiştirilmesinden çıkarılabilir. Bu durum değişikliğinin zaman damgası kullanılır.
Yakalayın
'Müşteri bekleniyor' olarak belirlenmiş duruma yapılan statuscode değişikliğinin zaman damgasını izleyin.
Olay türü
inferred
|
|||
|
Müşteriye çözüm önerildi
|
Bu aktivite, temsilcinin bir çözüm oluşturup müşteriye ilettiğini gösterir. Genellikle vaka zaman çizelgesinden gönderilen bir giden e-postadan veya durumun 'Müşteri Onayı Bekleniyor' olarak değiştirilmesinden çıkarılır. | ||
|
Neden önemli?
Bu kilometre taşı, inceleme aşamasından çözüme geçişi gösterir. Çözümün önerilmesi ile onaylanması arasındaki süreyi analiz etmek, müşterinin yanıtındaki gecikmeleri veya önerilen düzeltmelerle ilgili sorunları ortaya çıkarabilir.
Nereden alınır?
Vakayla ilişkili giden bir 'E-posta' aktivite kaydının zaman damgasından veya statuscode alanının çözüm öncesi bir duruma değiştirilmesinden çıkarılabilir.
Yakalayın
Giden e-posta aktivitesinin zaman damgasını veya durumun 'Çözüm Önerildi' olarak değiştirilmesini kullanın.
Olay türü
inferred
|
|||
|
Temsilci sorunu inceledi
|
Temsilcinin müşterinin sorununu anlamak ve teşhis etmek için etkin biçimde çalışmasını ifade eder. Bu, genellikle temsilcinin bir Knowledge Article'ı kayda bağlamasıyla belirlenen çıkarımsal bir etkinliktir ve araştırma yapıldığını gösterir. | ||
|
Neden önemli?
Bunu izlemek, bilgi kaynaklarının kullanımını ve bunların çözüm süreleri üzerindeki etkisini ölçmeye yardımcı olur. Temsilcilerin sorunları verimli biçimde çözmek için mevcut araçlardan yararlanıp yararlanmadığı konusunda içgörü sağlar.
Nereden alınır?
Bir Knowledge Article'ı Case'e bağlayan 'IncidentKnowledgeBaseRecord' varlığında kayıt oluşturulmasından çıkarılır. Bu kaydın oluşturulma zaman damgası kullanılır.
Yakalayın
Bir Knowledge Article'ın Incident ile ilişkilendirildiği zaman damgasını kullanın.
Olay türü
inferred
|
|||
|
Vaka yeniden etkinleştirildi
|
Daha önce çözümlenmiş bir vaka, genellikle müşterinin yanıt vermesi veya sorunun çözülmediğini bildirmesi nedeniyle otomatik ya da manuel olarak yeniden açıldığında gerçekleşir. Bu, vaka durumunu 'Çözümlendi' durumundan tekrar 'Etkin' durumuna getiren standart bir sistem davranışıdır. | ||
|
Neden önemli?
Bu aktivite, yeniden çalışmayı belirlemek ve 'İlk Temasta Çözüm Oranı'nı analiz etmek için önemlidir. Yeniden etkinleştirme sayısının yüksek olması, ilk çözümlerin eksik veya etkisiz olduğuna işaret eder.
Nereden alınır?
'Incident' varlığındaki 'statecode' alanının 'Çözümlendi' (1) durumundan tekrar 'Etkin' (0) durumuna değiştirilmesiyle kaydedilir. Bu değişikliğin zaman damgası denetim geçmişine yazılır.
Yakalayın
Denetim günlüklerinde 'statecode' alanının Çözümlendi durumundan Etkin durumuna değiştiği zaman damgasını izleyin.
Olay türü
explicit
|
|||
Veri Çıkarma Rehberleri
Başlamaya hazır mısınız?
Process Mining yolculuğunuza hızlıca başlamak ve müşteri hizmetleri operasyonlarınızdaki yeni verimlilik fırsatlarını ortaya çıkarmak için bu veri Templateinden yararlanın. Daha iyi müşteri deneyimleri sunmak üzere iş akışlarınızı bugün optimize etmeye başlayın.
Müşteri hizmetlerini optimize edin: FCR'yi artırın, maliyetleri şimdi azaltın
Darboğazları belirleyin ve daha memnun müşteriler için ilk temasta %80 çözüm oranına ulaşın.
Kredi kartı gerekmez. Dakikalar içinde kurulumu tamamlayın.