Müşteri hizmetleri Veri Seti Templateiniz
Müşteri hizmetleri Veri Seti Templateiniz
Bu, Müşteri Hizmetleri için genel Process Mining veri Templateimizdir. Daha özel yönlendirme için sisteme özel Templatelerimizi kullanın.
Belirli bir sistem seçin- Tutarlı analiz için standart veri alanları
- Doğru süreç haritalama için temel aktiviteler
- Farklı sistemlerde kullanılabilen temel yapı
Müşteri hizmetleri öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Faaliyet Activity | Belirli bir hizmet talebi için müşteri hizmetleri sürecinde gerçekleşen iş olayının, görevinin veya adımının adı. | ||
| Açıklama Etkinlik, bir hizmet talebinin yaşam döngüsündeki belirli bir adımı veya olayı ifade eder. Örnekler arasında 'Hizmet talebi oluşturuldu', 'Talep atandı', 'Çözüm önerildi' ve 'Talep kapatıldı' yer alır. Her etkinlik belirli bir hizmet talebiyle ilişkilidir ve gerçekleştiği zamanı gösteren bir zaman damgasına sahiptir. Bu öznitelik, müşteri hizmetleri iş akışının görsel temsili olan süreç haritasını oluşturmak için gereklidir. Etkinliklerin sırasını ve sıklığını analiz ederek hizmet taleplerinin gerçekte izlediği yolları ortaya çıkarabilirsiniz. Böylece yaygın iş akışlarını, darboğazları, sapmaları ve yeniden çalışma döngülerini görün. Bu öznitelik, her Process Mining analizinin temelini oluşturur. Neden önemli? Bu öznitelik, süreç haritanızdaki adımları tanımlar. Hangi işlerin yapıldığını ve hangi sırayla ilerlediğini anlamak için gereklidir. Nereden alınır? Genellikle müşteri hizmetleri sistemindeki Event Loglarından, durum değişikliği tablolarından veya denetim izi kayıtlarından elde edilir. Örnekler Talep oluşturulduTalep atandıİlk yanıt gönderildiTalep çözüldü | |||
| Hizmet Talebi Kimliği ServiceRequestId | Tek bir müşteri talebini veya sorununu tanımlayan benzersiz kimliktir. Bu kimlik, ilgili tüm faaliyetleri tek bir vakada birleştirir. | ||
| Açıklama Hizmet Talebi Kimliği, her müşteri vakasını oluşturulmasından nihai çözümüne kadar benzersiz biçimde tanımlayan birincil anahtardır. Vaka kimliği olarak görev yapar ve belirli bir müşteri sorunuyla ilgili tüm olayları, iletişimleri ve işlemleri tutarlı bir zaman çizelgesinde bir araya getirir. Process Mining kapsamında bu öznitelik, her hizmet talebinin uçtan uca yolculuğunu yeniden oluşturmak için temel niteliktedir. Analistler, her faaliyeti belirli bir Hizmet Talebi Kimliğiyle ilişkilendirerek süreç akışlarını görselleştirebilir, sapmaları belirleyebilir ve vaka sürelerini doğru biçimde ölçebilir. Bu sayede süreci vaka merkezli olarak incelemek mümkün olur. Bu görünüm, performansı anlamak ve iyileştirme alanlarını belirlemek için gereklidir. Neden önemli? Bu, temel vaka kimliğidir. Bu kimlik olmadan tek bir müşteri sorununun süreçteki yolculuğunu izleyemezsiniz. Nereden alınır? Genellikle müşteri hizmetleri yönetim sistemindeki vaka, talep veya olay kayıtlarının üst bilgi bölümünde ya da ana tablosunda bulunur. Örnekler SR-2023-00123CASE009876TKT-554321INC0123456 | |||
| Olay Zamanı EventTime | Belirli bir faaliyetin veya olayın gerçekleştiği kesin tarih ve saati gösteren zaman damgası. | ||
| Açıklama Başlangıç zamanı olarak da bilinen Olay zamanı, bir etkinliğin gerçekleştiği anı gösterir. Hizmet talebinin ilk oluşturulmasından son kapatılmasına kadar günlükteki her olay bir zaman damgasıyla işaretlenir. Bu zamansal veri, olayları kronolojik sıraya koymak için gereklidir. Belirli bir hizmet talebine ait bu zaman damgalarının sırası, Process Mining araçlarının süreç akışını gerçekte gerçekleştiği biçimde yeniden oluşturmasını sağlar. Olay zamanı, etkinlikler arasındaki süreyi hesaplama, toplam vaka çözüm süresini ölçme, darboğazları belirleme ve hizmet düzeyi anlaşmalarına (SLA) uyumluluğu kontrol etme dahil tüm zaman temelli analizlerin temelidir. Neden önemli? Bu zaman damgası olayları sıralar ve çözüm sürelerini hesaplama, darboğazları belirleme gibi süreye dayalı tüm analizleri mümkün kılar. Nereden alınır? Event Loglarında veya denetim izi tablolarında, çoğu zaman etkinlik adıyla birlikte bulunur. 'Oluşturma tarihi', 'Olay tarihi' veya 'Timestamp' olarak adlandırılabilir. Örnekler 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:05:00Z | |||
| Kaynak Sistem SourceSystem | Verilerin çıkarıldığı kayıt sistemi. Veri kökenini izlemek için kullanışlıdır. | ||
| Açıklama Kaynak Sistem özniteliği, müşteri hizmetleri verilerinin ServiceNow, Salesforce, Zendesk veya kurum içinde geliştirilen özel bir sistem gibi hangi uygulama ya da platformdan geldiğini tanımlar. Birden fazla sistemden gelen verilerin birleştirildiği ortamlarda bu alan, veri yönetişimi ve izlenebilirlik için büyük önem taşır. Çoğu standart süreç akışı analizinde doğrudan kullanılmasa da önemli bir bağlam sağlar. Farklı sistemlerdeki veri kalitesi veya süreç yürütme farklılıklarını anlamaya yardımcı olur. Ayrıca veri doğrulama, veri çıkarma sorunlarını giderme ve veri entegrasyonu hatlarını yönetme açısından da gereklidir. Neden önemli? Verinin kaynağını gösterir. Çok sistemli ortamlarda veri yönetişimi, sorun giderme ve analiz için gereklidir. Nereden alınır? Genellikle veri çıkarma (ETL) sürecinde eklenir ve kaynak sistem tablolarında doğrudan bulunmayabilir. Örnekler Salesforce Service CloudZendesk SupportServiceNow CSM | |||
| Son Veri Güncellemesi LastDataUpdate | Verilerin kaynak sistemden en son yenilendiği zamanı gösteren zaman damgası. | ||
| Açıklama Son Veri Güncellemesi özniteliği, en son veri çıkarma veya yenileme işleminin tarih ve saatini kaydeder. Bu meta veri, analiz edilen verinin güncelliğini anlamak ve veri hattını yönetmek için gereklidir. Bu öznitelik, iş kullanıcılarına ve analistlere analizlerinin ne kadar güncel olduğunu gösterir. Veri yenilemelerini planlamaya yardımcı olur ve kararların ihtiyaç duyulan güncellikteki verilere dayanmasını sağlar. Devam eden süreçleri izlerken son güncelleme zamanını bilmek, açık vakaların mevcut durumunu doğru yorumlamak için önemlidir. Neden önemli? Verinin güncelliğini gösterir ve analizlerin ve iş kararlarının zamanında elde edilen, ilgili bilgilere dayanmasını sağlar. Nereden alınır? Bu zaman damgası genellikle veri çıkarma (ETL) sürecinde oluşturulur ve eklenir. Örnekler 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
| Atanan Grup AssignedGroup | Hizmet talebinin atandığı ekip, departman veya kuyruk. | ||
| Açıklama Atanan Grup, belirli bir zamanda bir hizmet talebinden sorumlu ekibi veya işlevsel birimi tanımlar. Bu değer Level 1 Support, Faturalama Departmanı veya Teknik Destek Ekibi olabilir. Hizmet talepleri ilerledikçe genellikle farklı gruplara yönlendirilir. Atanan Grubu analiz etmek, ekipler arası iş birliğini ve devirleri anlamak için önemlidir. Hangi ekiplerin aşırı yüklendiğini, gruplar arasındaki darboğazların nerede oluştuğunu ve farklı talep türlerinin kurum içinde hangi yolları izlediğini belirlemeye yardımcı olur. Bu bilgiler ekip yapılarını, kaynak dağılımını ve yönlendirme kurallarını iyileştirmek için gereklidir. Neden önemli? Ekip performansını ve iş yükü dağılımını analiz etmeyi, farklı departmanlar arasındaki devirlerin neden olduğu gecikmeleri belirlemeyi sağlar. Nereden alınır? Vaka veya talep kaydında bulunur. Genellikle Assignment Group, Team veya Queue gibi alanlarda yer alır. Örnekler 1. Seviye DestekFaturalandırma talepleriTeknik eskalasyonlarDonanım desteği | |||
| Bitiş Zamanı EndTime | Bir faaliyetin tamamlandığı zamanı gösteren zaman damgası. Tek tek faaliyetlerin süresini hesaplamak için kullanılır. | ||
| Açıklama Bitiş Zamanı özniteliği, bir faaliyetin tamamlandığı noktayı gösterir. Olay Zamanı başlangıcı belirtirken Bitiş Zamanı, belirli bir görevin ne kadar sürdüğünü ölçmek için gereken diğer noktayı sağlar. Her olayın ayrı bir bitiş zamanı olmayabilir. Ancak Temsilci İncelemesi veya müşteri görüşmesi gibi faaliyetlerde bu bilgi değerlidir. Analizde Bitiş Zamanı ile Olay Zamanı arasındaki fark, faaliyetin işlem süresini verir. Bu bilgi, süreçte en fazla zaman alan adımları bulmayı amaçlayan darboğaz analizinin temelidir. Faaliyet sürelerini anlamak, kaynak planlamasına ve performans değerlendirmesine yardımcı olur, ayrıca operasyonları hızlandırma fırsatlarını ortaya çıkarır. Neden önemli? Bu öznitelik, tek tek faaliyetlerin sürelerini hesaplamak için gereklidir. Darboğazları belirlemeye ve verimliliği ölçmeye yardımcı olur. Nereden alınır? Genellikle Event Loglarında veya denetim izi tablolarında başlangıç zamanının yanında bulunur. Mevcut değilse sonraki olayın başlangıç zamanından türetilmesi gerekebilir. Örnekler 2023-10-26T10:30:00Z2023-10-26T11:00:45Z2023-10-27T16:20:00Z | |||
| İletişim Kanalı CommunicationChannel | Hizmet talebinin başlatıldığı veya iletişimin gerçekleştiği kanal. Örnekler arasında Email, Phone ve Chat bulunur. | ||
| Açıklama İletişim Kanalı, müşterinin hizmet masasıyla etkileşim kurmak için kullandığı ortamı tanımlar. Yaygın kanallar arasında e-posta, telefon, web portalı, sohbet ve sosyal medya bulunur. Kanal, müşteri beklentilerini ve çözüm sürecinin karmaşıklığını etkileyebilir. Süreci iletişim kanalına göre analiz etmek, performansta önemli farklılıkları ortaya çıkarabilir. Örneğin telefonla iletilen talepler, web portalından gelen taleplere göre daha hızlı çözülebilir ancak temsilcilerden daha fazla kaynak gerektirebilir. Bu analiz, kurumların kanal stratejisini iyileştirmesine, kaynakları doğru dağıtmasına ve hizmet deneyimini farklı iletişim yöntemlerine göre uyarlamasına yardımcı olur. Neden önemli? Farklı iletişim kanallarının çözüm sürelerini, temsilci emeğini ve genel süreç verimliliğini nasıl etkilediğini gösterir. Nereden alınır? Genellikle vaka veya talep kaydında, talebin nasıl oluşturulduğunu gösteren standart bir alan olarak bulunur. Örnekler E-postaTelefonSohbetWeb PortalıSosyal medya | |||
| Müşteri Memnuniyeti CustomerSatisfaction | Hizmet talebi çözümlendikten sonra müşterinin verdiği memnuniyet puanı veya değerlendirmesi. | ||
| Açıklama Müşteri Memnuniyeti, müşterinin aldığı hizmete ilişkin algısını ölçen önemli bir sonuç metriğidir. Genellikle çözüm sonrasında yapılan bir anketle, 1 ile 5 arasındaki sayısal bir ölçekte veya Good, Neutral ve Bad gibi kategorik bir değerlendirmeyle toplanır. Bu öznitelik, süreç performansını iş sonuçlarıyla ilişkilendirmek için gereklidir. Analistler memnuniyet puanlarını süreç metrikleriyle ilişkilendirerek hangi süreç davranışlarının memnun veya memnun olmayan müşterilere yol açtığını belirleyebilir. Örneğin analiz, birden fazla kez yeniden atanan veya uzun sürede çözülen vakaların sürekli olarak düşük memnuniyet puanı aldığını gösterebilir. Bu bilgi, müşteri deneyimi üzerinde en büyük etkiyi yaratacak süreç iyileştirmelerine öncelik vermek için veriye dayalı bir temel sağlar. Neden önemli? Müşterinin hizmet kalitesi algısını doğrudan ölçer ve süreç verimliliğini iş sonuçlarıyla ilişkilendirir. Nereden alınır? Genellikle hizmet talebi kaydıyla ilişkilendirilebilen ayrı bir anket yanıtları tablosunda saklanır. Örnekler 5413 | |||
| Öncelik Priority | Low, Medium, High veya Urgent gibi hizmet talebine atanan öncelik düzeyi. | ||
| Açıklama Öncelik özniteliği, bir hizmet talebinin aciliyetini gösterir ve genellikle talebin ne kadar hızlı ele alınması gerektiğini belirler. Bu düzey çoğunlukla müşterinin bildirdiği sorunun iş etkisine ve önem derecesine göre belirlenir. SLA'lar genellikle öncelik düzeyine bağlıdır. Süreç analizinde öncelik, filtreleme ve karşılaştırma için önemli bir boyuttur. Analistler, beklendiği gibi yüksek öncelikli taleplerin düşük öncelikli taleplerden daha hızlı çözülüp çözülmediğini kontrol edebilir. Önceliklendirme kurallarına uyulup uyulmadığını doğrulamaya ve kaynak dağılımının iş öncelikleriyle uyumunu değerlendirmeye yardımcı olur. Farklı öncelik düzeylerine ait süreç akışlarını karşılaştırmak, kritik sorunların ele alınmasındaki verimsizlikleri ortaya çıkarabilir. Neden önemli? Acil taleplerin daha hızlı ele alınıp alınmadığını analiz etmeyi ve kaynakların iş ihtiyaçlarıyla uyumlu olduğunu doğrulamayı sağlar. Nereden alınır? Çoğu müşteri hizmetleri sisteminde vaka veya talep formunda bulunan standart bir alandır. Örnekler DüşükOrtaYüksekAcil | |||
| Talep Durumu RequestStatus | Open, Pending, Resolved veya Closed gibi hizmet talebinin mevcut ya da geçmiş durumu. | ||
| Açıklama Talep Durumu, bir hizmet talebinin yaşam döngüsünün belirli bir anındaki durumunu gösterir. Talep üzerinde çalışıldıkça durum değişir. Örneğin New durumundan In Progress'e, ardından Pending Customer'a ve son olarak Resolved durumuna geçebilir. Durum değişikliklerinin sırası, süreç modelindeki faaliyetlerin temelini oluşturur. Durum değişikliklerini analiz etmek, süreç akışını anlamanın başlıca yollarından biridir. Taleplerin Pending gibi belirli durumlarda ne kadar beklediğini gösterir ve dış taraflara bağlı gecikmeleri ortaya çıkarabilir. Ayrıca açık ve kapalı vakaları ayırt etmek için kullanılır. Bu ayrım, aktif vaka yükünü ve çözüm oranlarını raporlamak açısından gereklidir. Neden önemli? Talebin yaşam döngüsündeki aşamayı izler, bekleme durumlarında geçirilen süreyi belirlemeye ve süreç faaliyetlerini tanımlamaya yardımcı olur. Nereden alınır? Vaka veya talep kaydındaki temel alanlardan biridir. Durum değişiklikleri genellikle denetim geçmişi tablosuna kaydedilir. Örnekler YeniDevam ediyorMüşteri yanıtı bekleniyorÇözüldüKapalı | |||
| Talep Türü RequestType | Question, Incident, Problem veya Feature Request gibi hizmet talebi sınıflandırması. | ||
| Açıklama Talep türü, müşterinin sorununun veya bilgi talebinin üst düzey kategorisini sunar. Bu sınıflandırma, destek organizasyonuna yöneltilen farklı talep türlerini anlamak için hizmet taleplerini segmentlere ayırmaya yardımcı olur. Yaygın türler arasında teknik sorunlar, faturalama soruları, bilgi talepleri ve şikâyetler bulunur. Bu öznitelik analiz için çok değerlidir. Farklı talep türlerine ait süreçleri filtrelemenize ve karşılaştırmanıza olanak tanır. Örneğin 'Faturalama sorusu' için çözüm süreci, 'Teknik olay' için gerekenden çok daha basit ve hızlı olabilir. Bu farkları anlamak, uygun SLA’lar belirlemek, verimli iş akışları tasarlamak ve kaynakları etkili biçimde dağıtmak için önemlidir. Neden önemli? Talepleri türlerine göre bölümlere ayırmak, farklı süreç yollarını anlamak ve iyileştirmeleri belirli sorunlara göre uyarlamak için gereklidir. Nereden alınır? Ana vaka veya talep formunda bulunan standart bir alandır. Genellikle Type, Category veya Classification olarak adlandırılır. Örnekler OlaySoruSorunÖzellik talebi | |||
| Temsilci Agent | Bir faaliyetten sorumlu müşteri hizmetleri temsilcisinin veya kullanıcının adı ya da benzersiz kimliği. | ||
| Açıklama Temsilci özniteliği, belirli bir faaliyeti gerçekleştiren veya bir hizmet talebine atanmış olan çalışanı tanımlar. Bu değer benzersiz bir kimlik, e-posta adresi veya tam ad olabilir. Bu öznitelik, bireysel düzeyde performans ve iş yükü analizi yapılmasını sağlar. Yöneticiler iş dağılımını görebilir, temsilcilerin çözüm süresi veya müşteri memnuniyeti gibi metriklerdeki performansını karşılaştırabilir ve eğitim fırsatlarını belirleyebilir. Ayrıca gecikmelere ve müşteri memnuniyetsizliğine yol açabilen temsilciler arası devirleri analiz etmek için de gereklidir. Neden önemli? Bu öznitelik, temsilci iş yükünü ve performansını analiz etmek, ayrıca farklı temsilciler arasındaki devirlerin etkisini görmek için gereklidir. Nereden alınır? Genellikle vaka atama geçmişi tablolarında, Event Loglarında veya ana vaka ya da ticket kaydındaki bir alanda bulunur. Örnekler John Smithagent.jane@example.comuser_1138Sarah Doe | |||
| Yükseltildi mi IsEscalated | Hizmet talebinin daha üst düzey bir destek veya yönetim birimine aktarılıp aktarılmadığını gösteren işaret. | ||
| Açıklama Yükseltildi mi özniteliği, bir hizmet talebinin resmi olarak üst düzeye aktarıldığını belirten doğru/yanlış değerli bir işarettir. Yükseltme genellikle sorunun mevcut destek kademesi için fazla karmaşık olması, belirlenen süre içinde çözülememesi veya müşterinin ciddi biçimde memnuniyetsiz olması durumunda gerçekleşir. Bu öznitelik, yükseltme analizleri için gereklidir. Kurumların önemli bir performans göstergesi olan yükseltme oranını hesaplamasını sağlar. Yükseltilen vakaların süreç akışını analiz ederek ön saflardaki destekteki beceri eksiklikleri, belirsiz süreçler veya ürün sorunları gibi temel nedenler belirlenebilir. Yükseltmeleri azaltmak genellikle önemli bir hedeftir; çünkü bu vakalar maliyetlidir ve müşteri memnuniyetini olumsuz etkileyebilir. Neden önemli? Yükseltmelerin sıklığını ve temel nedenlerini belirlemeye, ilk temas çözümünü iyileştirme fırsatlarını ortaya çıkarmaya yardımcı olur. Nereden alınır? Genellikle vaka veya talep kaydında bir onay kutusu ya da işaret alanıdır. Ayrıca Escalate faaliyeti belirlenerek de türetilebilir. Örnekler truefalse | |||
| Müşteri Customer | Hizmet talebini başlatan müşterinin veya şirketin adı ya da benzersiz kimliği. | ||
| Açıklama Müşteri özniteliği, hizmet talebiyle ilişkili dış müşteriyi, yani kişiyi veya kurumu tanımlar. Bu sayede belirli bir müşteriye ait tüm hizmet etkileşimleri gruplanabilir ve analiz edilebilir. Müşteri merkezli görünüm, genel müşteri deneyimini anlamak için gereklidir. İşletmeler müşteri bazında filtrelenmiş verileri analiz ederek çok sayıda talep gönderen müşterileri belirleyebilir. Bu durum üründeki sorunlara veya daha iyi eğitim ihtiyacına işaret edebilir. Ayrıca önemli müşterilerin hizmet geçmişini izlemeye ve beklenen destek düzeyini alıp almadıklarını kontrol etmeye yardımcı olur. Neden önemli? Süreci müşteri merkezli olarak incelemeyi, belirli müşterilerde tekrarlanan sorunları belirlemeyi ve önemli müşteri hesaplarını yönetmeyi sağlar. Nereden alınır? Vaka veya talep kaydındaki standart bir alandır ve CRM'deki kişi veya hesap nesnesine bağlanır. Örnekler ABC CorporationGlobal Tech Inc.Jane DoeACCT-00123 | |||
| SLA Hedef Zamanı SlaTargetTime | Hizmet talebinin çözümlenmesi için sözleşmeyle kararlaştırılan veya hedeflenen tarih ve saat. | ||
| Açıklama SLA Hedef Zamanı, geçerli Service Level Agreement (SLA) uyarınca bir hizmet talebinin çözümlenmesinin beklendiği son tarihi ve saati gösterir. Bu hedef genellikle talebin önceliğine, türüne veya müşterinin sözleşme düzeyine bağlıdır. Belirli bir zaman damgası olarak ya da oluşturulma zamanından itibaren geçen süre şeklinde saklanabilir. Bu öznitelik, SLA uyumluluğu analizinin temelidir. Kurumlar gerçek çözüm süresini SLA Hedef Zamanıyla karşılaştırarak SLA uyumluluk oranını belirleyebilir. Process Mining, bu analizi daha ayrıntılı hale getirerek hangi talep türlerinin veya süreç adımlarının SLA ihlallerine en fazla katkıda bulunduğunu gösterebilir. Böylece hizmet taahhütlerini karşılamak için hedefli iyileştirmeler yapılabilir. Neden önemli? Müşteri hizmetleri kuruluşları için önemli bir KPI olan SLA uyumluluğunu ölçmek açısından gereklidir. Nereden alınır? Genellikle sistemde tanımlanan SLA politikalarına göre hesaplanır ve vaka veya talep kaydında saklanır. Örnekler 2023-10-28T10:00:00Z2023-11-01T17:00:00Z2023-10-26T14:00:00Z | |||
| Ürün Product | Müşterinin talebinin ilgili olduğu ürün veya hizmet. | ||
| Açıklama Ürün özniteliği, müşterinin talebinin konusu olan belirli ürünü, hizmeti veya özelliği belirtir. Bu sayede hizmet talepleri, ilgili oldukları iş alanına göre sınıflandırılabilir. Hizmet taleplerini ürüne göre analiz etmek, temel neden analizi ve ürün iyileştirme için önemlidir. Belirli bir ürünle ilgili yüksek talep hacmi kalite sorunlarına, hatalara veya kullanılabilirlik problemlerine işaret edebilir. Bu veri, ürün geliştirme ve mühendislik ekiplerine değerli geri bildirim sağlayarak destek iş yükünü azaltacak ve müşteri deneyimini iyileştirecek düzeltme ve geliştirmelere öncelik vermelerine yardımcı olur. Neden önemli? Hizmet taleplerini belirli ürünlerle ilişkilendirerek ürün iyileştirme ve temel neden analizi için önemli geri bildirim sağlar. Nereden alınır? Genellikle vaka veya talep formunda bulunan ve ürün kataloğuna bağlanan ya da elle doldurulabilen bir alandır. Örnekler Alpha-100 YazıcıEnterprise Suite v2.5Mobil uygulamaFaturalandırma platformu | |||
Müşteri hizmetleri aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Hizmet talebi oluşturuldu | Müşterinin talebinin resmi olarak kayda alınmasıyla müşteri hizmetleri sürecinin başladığını gösterir. Bu olay, kaynak sistemde yeni bir vaka, ticket veya etkileşim kaydı oluşturulduğunda yakalanır. | ||
| Neden önemli? Bu, süreçteki birincil başlangıç olayıdır. Toplam yaşam döngüsü süresini ölçmek ve zaman içindeki gelen talep hacimlerini analiz etmek için gereklidir. Nereden alınır? Genellikle hizmet yönetimi sistemindeki birincil vaka veya ticket kaydının oluşturulma zaman damgasından alınır. Yakalayın Ana vaka, ticket veya incident varlığının oluşturulma zaman damgasını kullanın. Olay türü explicit | |||
| Talep atandı | Bir hizmet talebinin ilk kez işlenmek üzere belirli bir temsilciye veya ekibe atanmasını ifade eder. Bu önemli adım, talebi kuyruktan çıkararak aktif bir iş akışına taşır. | ||
| Neden önemli? Bu faaliyet, temsilci iş yükünü izlemek, ilk atamaya kadar geçen süreyi ölçmek ve dağıtım sürecindeki darboğazları belirlemek için önemlidir. Nereden alınır? Hizmet talebi kaydının denetim günlüğünde veya geçmişinde 'Owner' ya da 'Assigned To' alanlarında yapılan değişikliklerden alınır. Yakalayın Temsilci veya grup sahibi alanının ilk kez doldurulduğu ya da değiştirildiği olayı belirleyin. Olay türü explicit | |||
| Talep çözüldü | Temsilcinin çalışmayı tamamladığı ve müşterinin sorununun giderildiğini kabul ettiği önemli bir kilometre taşıdır. Talep 'Resolved' veya 'Solved' durumuna taşınır. | ||
| Neden önemli? Bu, çözüm süresini ölçmek için kullanılan birincil olaydır. Destek ekibinin aktif çalışmasının tamamlandığını gösterir ve hizmet yaşam döngüsünde önemli bir kilometre taşıdır. Nereden alınır? 'Resolved' veya 'Solved' durumuna yapılan açık bir durum değişikliğinden alınır. Çoğu sistem özel bir çözüm zaman damgası kaydeder. Yakalayın 'Resolved At' zaman damgasını veya durumun 'Resolved' değerine değiştiği zaman damgasını kullanın. Olay türü explicit | |||
| Talep eskale edildi | Bir hizmet talebinin daha üst bir destek kademesine, farklı bir departmana veya yönetime resmi olarak aktarılmasını ifade eder. Bu durum, ilk temsilcinin sorunu çözememesi halinde gerçekleşir. | ||
| Neden önemli? Eskalasyonlar süreç karmaşıklığının, temsilci yetkinliğinin ve ilk temasta çözüm başarısızlıklarının önemli göstergeleridir. Eskalasyon yollarını analiz etmek, destek yapılarını optimize etmeye yardımcı olur. Nereden alınır? Eskalasyon kuralı motorundan gelen açık bir olay olabilir veya belirlenmiş bir eskalasyon ekibine ya da kullanıcıya yapılan yeniden atamadan çıkarılabilir. Yakalayın Özel bir eskalasyon işareti veya zaman damgası kullanın ya da atamanın bilinen bir eskalasyon ekibine değiştiğini belirleyin. Olay türü explicit | |||
| Talep kapatıldı | Hizmet talebinin kalıcı ve idari olarak kapatılmasını ifade eden son faaliyettir. Bu noktadan sonra talep tamamlanmış kabul edilir ve başka bir işlem beklenmez. | ||
| Neden önemli? Bu faaliyet, süreç yaşam döngüsünün kesin sonunu gösterir. Çözüm ile kapatma arasındaki süre, otomatik kapatma veya son incelemeyle ilgili süreç politikalarını ortaya çıkarabilir. Nereden alınır? 'Closed' durumuna yapılan açık bir durum değişikliğinden alınır. Birçok sistemde özel bir 'Closed At' zaman damgası bulunur. Yakalayın 'Closed At' zaman damgasını veya durumun 'Closed' değerine değiştiği zaman damgasını kullanın. Olay türü explicit | |||
| Talep yeniden açıldı | Daha önce çözülmüş bir hizmet talebinin yeniden aktif duruma alınmasıyla gerçekleşir. Bu genellikle müşterinin sorunun çözülmediğini veya yeniden ortaya çıktığını bildirmesi halinde olur. | ||
| Neden önemli? Yeniden açılan talepler, yeniden çalışmanın doğrudan ölçüsüdür ve ilk temasta çözüm başarısızlığının güçlü bir göstergesidir. Bu olayları analiz etmek, çözüm kalitesini artırmak için önemlidir. Nereden alınır? Genellikle müşteri yeni bir yanıt gönderdiğinde sistemin durumu otomatik olarak 'Resolved' değerinden 'Open' değerine değiştirdiği açık bir olaydır. Yakalayın Durumun 'Resolved' veya 'Closed' değerinden yeniden 'Open' ya da 'In Progress' değerine değişmesini belirleyin. Olay türü explicit | |||
| Talep yeniden atandı | Bir hizmet talebinin sorumluluğunun ilk atamadan sonra bir temsilciden veya ekipten diğerine aktarılmasını gösterir. Bu, destek sürecindeki bir devirdir. | ||
| Neden önemli? Yeniden atamaları izlemek, süreç parçalanmasını analiz etmek ve gereksiz devirleri belirlemek için önemlidir. Sık yeniden atamalar, yönlendirme sorunlarına veya bilgi eksikliklerine işaret edebilir. Nereden alınır? İlk atamadan sonra 'Owner', 'Assigned To' veya 'Assignment Group' alanlarında yapılan sonraki değişiklikler izlenerek çıkarılır. Yakalayın İlk atamadan sonra sahip veya atama grubu alanlarında yapılan tüm değişiklikleri belirleyin. Olay türü inferred | |||
| Çözüm önerildi | Bir temsilcinin çözüm oluşturup bunu müşteriye ilettiğini gösterir. Özellikle müşterinin onayı gerekiyorsa bu faaliyet resmi çözümden önce gerçekleşebilir. | ||
| Neden önemli? Bu kavramsal adım, çözüm bulmak için geçen süre ile müşterinin kabulünü beklemek için geçen süreyi ayırt etmeye yardımcı olur. Çözüm aşamasına ilişkin daha ayrıntılı bir görünüm sunar. Nereden alınır? Genellikle çözüm ayrıntılarını içeren dışa dönük bir iletişimden veya durumun 'Awaiting Acceptance' ya da 'Solution Provided' değerine değişmesinden çıkarılır. Yakalayın 'solution' gibi anahtar kelimeler içeren dışa dönük bir mesajı veya önerilen çözümü gösteren bir durum değişikliğini belirleyin. Olay türü inferred | |||
| İlk yanıt gönderildi | Talep oluşturulduktan sonra bir temsilcinin müşteriye gönderdiği ilk doğrudan ve otomatik olmayan iletişimi gösterir. Bu, müşteri etkileşimi açısından önemli bir kilometre taşıdır. | ||
| Neden önemli? Bu faaliyet, 'First Response Time' SLA'larını ölçmek ve izlemek için önemlidir. Destek ekibinin müşteri sorunlarıyla ne kadar hızlı ilgilenmeye başladığını gösterir. Nereden alınır? Genellikle sistemin SLA motorunda zaman damgalı açık bir olay olarak yer alır. Ayrıca vaka zaman çizelgesinde bir temsilciden gönderilen ilk dışa dönük herkese açık iletişim bulunarak da çıkarılabilir. Yakalayın Varsa özel 'First Response Time' zaman damgasını kullanın. Yoksa temsilcinin gönderdiği ilk dışa dönük mesajın zaman damgasını bulun. Olay türü explicit | |||
| Kurum içi yorum eklendi | Bir temsilcinin, diğer temsilciler veya ekiplerle kurum içi iş birliği amacıyla hizmet talebine müşteriye görünmeyen özel bir not ya da yorum eklemesidir. | ||
| Neden önemli? Bu olaylar kurum içi iş birliğini, bilgi paylaşımını veya eskalasyon hazırlığını gösterir. Kurum içi notların sık eklenmesi, vakanın karmaşık olduğuna veya bilgi eksikliklerine işaret edebilir. Nereden alınır? Hizmet talebinin faaliyet akışından veya iletişim günlüğünden, 'internal' ya da 'private' olarak işaretlenen yorumlar filtrelenerek alınır. Yakalayın Vaka yorumları veya faaliyet günlüğünü yalnızca kurum içinde görülebilen kayıtları gösterecek şekilde filtreleyin. Olay türü explicit | |||
| Memnuniyet anketi gönderildi | Genellikle bir hizmet talebi çözüldükten sonra otomasyon kuralıyla tetiklenen müşteri memnuniyeti anketinin gönderilmesini ifade eder. Bu, geri bildirim toplama sürecini başlatır. | ||
| Neden önemli? Bu faaliyet, müşteri geri bildirimi metrikleri için bağlam sağlar. Anket yanıt oranlarını ve geri bildirim taleplerinin zamanlamasını analiz etmeye yardımcı olur. Nereden alınır? Bir otomasyon günlüğünden, dışa dönük e-posta kaydından veya hizmet talebiyle ilişkilendirilmiş özel bir anket örneği kaydından alınır. Yakalayın Bir anket nesnesinin oluşturulmasını veya memnuniyet anketiyle ilgili dışa dönük bir iletişimi belirleyin. Olay türü explicit | |||
| Müşteri memnuniyeti alındı | Müşterinin memnuniyet anketine yanıt göndermesiyle gerçekleşir. Puan veya yorum gibi geri bildirimler hizmet talebiyle ilişkilendirilerek kaydedilir. | ||
| Neden önemli? Süreç yürütümü ile müşterinin algıladığı kalite arasında doğrudan bağlantı kurar. Memnuniyet puanlarını süreç bağlamında analiz etmek, kötü deneyimlere yol açan adımları belirlemeye yardımcı olur. Nereden alınır? Müşteri yanıtı gönderilip ilk hizmet talebiyle ilişkilendirildiğinde anket modülünden alınır. Yakalayın Müşteri memnuniyeti anketi yanıtının gönderilme zaman damgasını kullanın. Olay türü explicit | |||
| Müşteriden bilgi alındı | Müşterinin istenen bilgileri sağlayarak temsilcinin çalışmaya devam etmesini mümkün kıldığı anı gösterir. Bu olay genellikle talebi bekleyen durumdan yeniden aktif duruma taşır. | ||
| Neden önemli? Bu olay, müşterinin beklediği dönemi sona erdirir. Bu olay ile 'Information Requested' faaliyeti arasındaki sürenin analiz edilmesi, müşterinin yanıt verme süresini gösterir. Nereden alınır? Müşteriden gelen bir iletişimden veya durumun 'Pending' değerinden otomatik olarak 'Open' ya da 'In Progress' değerine değişmesinden çıkarılır. Yakalayın Müşteriden gelen bir mesajı veya durumun 'pending' değerinden 'active' değerine değişmesini belirleyin. Olay türü inferred | |||
| Müşteriden bilgi istendi | Bir temsilcinin devam edebilmek için müşteriden daha fazla bilgi istemesi ve talebi bekleyen duruma almasıyla gerçekleşir. Bu durum, kurum içi süreci veya SLA sayaçlarını duraklatır. | ||
| Neden önemli? Bu faaliyet, müşteri kaynaklı gecikmeleri anlamak için önemlidir. Bu durumun süresini izlemek, temsilcinin çalışma süresi ile müşterinin bekleme süresini ayırmaya yardımcı olur. Nereden alınır? Genellikle durumun 'Pending', 'On Hold' veya 'Awaiting Customer Info' gibi bir değere değiştirilmesinden çıkarılır. Yakalayın Vaka geçmişinde durumun 'pending' veya 'waiting on customer' değerine değiştiği kayıtları belirleyin. Olay türü inferred | |||
| SLA ihlal edildi | Bir hizmet talebinin ilk yanıt süresi veya çözüm süresi gibi tanımlanmış bir Hizmet Seviyesi Anlaşmasını karşılayamadığı anı gösterir. Bu, işletme açısından önemli bir olaydır. | ||
| Neden önemli? Bu faaliyet, hizmet seviyesi performansını ve uyumluluğunu doğrudan ölçer. İhlallerin ne zaman ve neden gerçekleştiğini analiz etmek, süreç iyileştirmesi ve müşteri beklentilerinin yönetimi için gereklidir. Nereden alınır? Bu, faaliyet zaman damgalarının hizmet sözleşmesinde veya politika motorunda tanımlanan SLA hedefleriyle karşılaştırılmasıyla elde edilen hesaplanmış bir olaydır. Yakalayın Başlangıç ve bitiş faaliyetleri arasındaki zaman damgası farkını tanımlanan SLA hedefiyle karşılaştırın. Süre hedefi aşarsa bir ihlal olayı kaydedin. Olay türü calculated | |||
| Talep kategorilendirildi | Bir hizmet talebinin türüne, kategorisine veya önceliğine göre sınıflandırılmasını ifade eder. Bu adım, aciliyeti ve yönlendirmeyi belirlemek için genellikle bir temsilci veya otomasyon kuralları tarafından gerçekleştirilir. | ||
| Neden önemli? Kategorilendirme değişikliklerini analiz etmek, ön değerlendirme etkinliğini, yeniden çalışmaları ve yanlış yönlendirilen talepleri belirlemeye yardımcı olur. Ayrıca hizmet taleplerinin karmaşıklığı ve niteliği hakkında bağlam sağlar. Nereden alınır? Genellikle hizmet talebi kaydındaki 'Category', 'Type' veya 'Priority' gibi alanlardaki değişiklikleri izleyen denetim günlüğünden veya geçmiş kaydından çıkarılır. Yakalayın Vaka geçmişindeki kategorilendirme, öncelik veya tür alanlarında yapılan değişiklikleri belirleyin. Olay türü inferred | |||
| Temsilci incelemeye başladı | Bir temsilcinin hizmet talebi üzerinde aktif olarak çalışmaya başladığını gösterir. Bu olay atamadan farklıdır ve teşhis veya çözüm çalışmalarının başlangıcını ifade eder. | ||
| Neden önemli? Bekleme süresi ile aktif çalışma süresini ayırt etmeye yardımcı olur. Bu faaliyetin analiz edilmesi, atama ile gerçek çalışmanın başlaması arasındaki gecikmeleri ortaya çıkarabilir. Nereden alınır? Genellikle hizmet talebinin durumunun 'New' veya 'Assigned' değerinden 'In Progress' ya da 'Work in Progress' değerine değişmesi gibi bir durum değişikliğinden çıkarılır. Yakalayın Atamadan sonra aktif bir 'in progress' durumuna yapılan ilk durum değişikliğini belirleyin. Olay türü inferred | |||
Veri çıkarma rehberleri
Çıkarma yöntemleri sisteme göre değişir. Ayrıntılı talimatlar için
Başlamaya hazır mısınız?
Veri hazırlamaya başlarken sisteme özel bir çıkarma rehberi seçin veya bu genel Templatei temel başlangıç noktası olarak kullanarak müşteri hizmetleri sürecinizi optimize etmeye başlayın.
Müşteri hizmetlerinde mükemmelliği şimdi yakalayın
Darboğazları ortaya çıkarın, temsilci verimliliğini artırın ve müşterilerinizi memnun edin.
Kredi kartı gerekmez, dakikalar içinde başlayın.