Hizmet talebi yönetimi veri şablonunuz
Hizmet talebi yönetimi veri şablonunuz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Veri çıkarma yönergeleri
Hizmet talebi yönetimi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Etkinlik adı
ActivityName
|
Bir hizmet talebi için belirli bir anda gerçekleşen olayın veya görevin adı. | ||
|
Açıklama
Etkinlik adı, hizmet talebinin yaşam döngüsündeki belirli bir adımı veya olayı tanımlar. Bu etkinlikler sistem denetim günlüklerinden, durum değişikliklerinden ya da kullanıcıların gerçekleştirdiği 'Talep destek uzmanına atandı', 'Not eklendi' veya 'Hizmet talebi çözüldü' gibi işlemlerden alınır. Süreç haritasını oluşturmak için bu öznitelikten yararlanılır. Harita, hizmet taleplerinin akışını görsel olarak gösterir. Farklı etkinliklerin sırasını ve sıklığını inceleyerek gerçek işleyişi anlayabilir, adımlar arasındaki darboğazları belirleyebilir, etkinlik sürelerini ölçebilir ve kurallara uymayan ya da verimsiz süreç varyantlarını tespit edebilirsiniz.
Neden önemli?
Bu öznitelik, süreç haritasındaki adımları tanımlar ve hizmet talebi iş akışını görselleştirip analiz etmenizi sağlar.
Nereden alınır?
Freshservice’teki bir kayıtla ilişkili 'activities' veya 'audits' verilerinden oluşturulur. Sistem olaylarını iş birimlerinin anlayacağı etkinlik adlarına dönüştürmek için genellikle bir dönüşüm mantığı gerekir.
Örnekler
Hizmet talebi oluşturulduTalep uzmana atandıHizmet talebi çözüldüHizmet talebi kapatıldı
|
|||
|
Hizmet talebi kimliği
ServiceRequestId
|
Her hizmet talebine ait benzersiz tanımlayıcı. | ||
|
Açıklama
Hizmet talebi kimliği, Freshservice’te kaydedilen her yeni hizmet talebine atanan benzersiz bir numara veya koddur. Talebin oluşturulmasından kapatılmasına kadar tüm yaşam döngüsünü izlemek için birincil anahtar görevi görür. Process Mining çalışmalarında bu kimlik, Vaka kimliği olarak kullanıldığı için temel bir alandır. Durum değişiklikleri, destek uzmanı atamaları ve notlar gibi ilgili tüm olaylar bu kimlikle ilişkilendirilir. Her hizmet talebi kimliğinin yolculuğunu inceleyerek süreci baştan sona görüntüleyebilir, sık izlenen yolları belirleyebilir ve vakaları etkileyen sapmaları ya da darboğazları tespit edebilirsiniz.
Neden önemli?
Bu temel Vaka kimliği, ilgili tüm olayları birbirine bağlayarak tek bir hizmet talebinin baştan sona izlenmesini sağlar.
Nereden alınır?
Freshservice’teki kayıt nesnesinin temel alanlarından biridir. Kullanıcı arayüzünde görünür ve Freshservice API üzerinden alınabilir.
Örnekler
SR-12943SR-13501SR-14011
|
|||
|
Olay zamanı
EventTime
|
Etkinliğin gerçekleştiği kesin zaman damgası. | ||
|
Açıklama
Olay zamanı, bir hizmet talebi için belirli bir etkinliğin kaydedildiği tarih ve saati gösterir. Olayları doğru sıraya koymak ve aralarındaki süreleri hesaplamak için bu zaman damgası gereklidir. Process Mining çalışmalarında bu öznitelik, her vaka için etkinlikleri sıralamakta kullanılır ve zamana dayalı tüm analizlerin temelini oluşturur. Çevrim sürelerini, etkinlikler arasındaki bekleme sürelerini ve hizmet seviyesi anlaşmalarına (SLA) uyumu hesaplamaya yardımcı olur. Darboğazları belirlemek ve süreç performansını anlamak için zaman damgalarının doğru olması gerekir.
Neden önemli?
Bu zaman damgası olayları kronolojik sıraya koyar; çevrim süresi ve darboğaz tespiti dahil tüm performans analizlerinin temelini oluşturur.
Nereden alınır?
Freshservice’teki bir etkinliğin veya denetim günlüğü kaydının oluşturulma zaman damgasına karşılık gelir.
Örnekler
2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
|
|||
|
Kaynak sistem
SourceSystem
|
Verinin alındığı sistemi belirtir. | ||
|
Açıklama
Bu öznitelik, süreç verisinin hangi sistemden geldiğini belirtir. Bu örnekte kaynak sistem Freshservice’tir. Birden fazla sistemden gelen verilerin süreçleri bütünsel olarak incelemek üzere birleştirildiği ortamlarda özellikle yararlıdır. Tek bir sistemin incelendiği durumlarda gereksiz görünebilir. Ancak ileride ölçeği büyütmek ve veri yönetişimini desteklemek için bu özniteliği eklemek iyi bir uygulamadır. Verinin kaynağını netleştirir ve veri entegrasyonu akışlarının yönetimine yardımcı olur.
Neden önemli?
Verinin kaynağını ve izlenebilirliğini güvence altına alır. Birden fazla sistemden gelen verileri birleştirirken veya veri yönetişimi için bu bilgi önemlidir.
Nereden alınır?
Genellikle veri çıkarma ve dönüştürme (ETL) işlemi sırasında eklenen sabit bir değerdir.
Örnekler
FreshserviceFreshservice-API-v2
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Verinin kaynak sistemden en son ne zaman yenilendiğini gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, Veri Setinin Freshservice’ten en son ne zaman alındığını veya güncellendiğini kaydeder. İncelenen verinin ne kadar güncel olduğunu anlamanıza yardımcı olur. Her süreç analizinde verinin güncelliğini bilmek önemlidir. Bu zaman damgası, en güncel bilgileri inceleyip incelemediğinizi anlamanızı sağlar. Böylece zamanında operasyonel kararlar alabilir ve analizden elde edilen sonuçlara güvenebilirsiniz.
Neden önemli?
Verinin ne kadar güncel olduğunu göstererek analizlerin ve kararların güncel bilgilere dayanmasını sağlar.
Nereden alınır?
Bu değer, veri çıkarma ve dönüştürme (ETL) işlemi sırasında oluşturulur ve Veri Setine eklenir.
Örnekler
2024-05-21T02:00:00Z2024-05-20T02:00:00Z
|
|||
|
Atanan destek uzmanı
AssignedAgent
|
Hizmet talebine o anda atanmış destek uzmanının adı. | ||
|
Açıklama
Bu öznitelik, belirli bir anda hizmet talebini ele almaktan sorumlu destek uzmanını belirtir. Talebin yaşam döngüsü boyunca atanan kişi değişebilir. Atanan destek uzmanını incelemek, uzman performansını ve iş yükü dağılımını anlamaya yardımcı olur. Uzman başına ortalama çözüm süresi, etkin talep sayısı ve yeniden atama oranı gibi temel performans göstergelerini (KPI) hesaplayabilirsiniz. Bu analiz, yüksek performans gösteren uzmanları, ek eğitime ihtiyaç duyabilecek kişileri ve iş yükü dağılımındaki dengesizlikleri belirlemeyi sağlar.
Neden önemli?
Destek uzmanlarının iş yükünü ve performansını, ayrıca yeniden atamaların çözüm sürelerine etkisini incelemenizi sağlar.
Nereden alınır?
Freshservice’teki kayıt nesnesinde 'agent' veya 'responder' alanı olarak bulunur.
Örnekler
Alice JohnsonRobert SmithAtanmamış
|
|||
|
Atanan ekip
AssignedTeam
|
Hizmet talebini ele almakla görevlendirilen destek ekibi veya grup. | ||
|
Açıklama
Bu öznitelik, hizmet talebinden sorumlu olan 'BT desteği, 2. düzey' veya 'Donanım tedariki' gibi işlevsel grubu ya da ekibi belirtir. Talep, bir destek uzmanına atanmasından önce bir ekibe yönlendirilebilir. Atanan ekibe göre analiz yapmak, ekip düzeyindeki performansı ve iş yükünü anlamaya, belirli işlev alanlarındaki darboğazları bulmaya yardımcı olur. Farklı ekiplerin talepleri ne kadar verimli işlediğini değerlendirmek ve destek kuruluşundaki kaynak dağılımını iyileştirmek için bu bilgi önemlidir.
Neden önemli?
Ekip veya grup düzeyinde performans ve iş yükü analizi yapmanızı sağlar. Kaynak yönetimi ve işlevsel darboğazların belirlenmesi için yararlıdır.
Nereden alınır?
Freshservice’teki kayıt nesnesinde 'group' alanı olarak bulunur.
Örnekler
Hizmet MasasıAğ operasyonlarıUygulama desteği
|
|||
|
Durum
Status
|
Hizmet talebinin yaşam döngüsündeki mevcut durumu. | ||
|
Açıklama
Durum alanı, hizmet talebinin belirli bir andaki durumunu gösterir. Örneğin 'Açık', 'Beklemede', 'Çözüldü' veya 'Kapalı' olabilir. Durum değişiklikleri, Process Mining analizlerinde etkinliklerin başlıca kaynaklarından biridir. Durumu incelemek, süreç akışını anlamlandırır ve taleplerin belirli durumlarda ne kadar kaldığını görmenizi sağlar. Örneğin, 'Beklemede' durumunun uzun sürmesi, talep sahibinden bilgi veya dış tedarikçiden yanıt beklenmesinden kaynaklanan bir darboğaza işaret edebilir. Farklı süreç aşamalarının başlangıç ve bitiş noktalarını belirlemek için de bu öznitelikten yararlanılır.
Neden önemli?
Her olay için gerekli bağlamı sağlar. Gecikmeleri belirlemek üzere 'Açık' veya 'Beklemede' gibi farklı durumlarda geçirilen süreyi ölçmenize yardımcı olur.
Nereden alınır?
Freshservice’teki kayıt nesnesinde 'status' alanı olarak bulunur.
Örnekler
AçıkBeklemedeÇözüldüKapalı
|
|||
|
Hizmet türü
ServiceType
|
Talep edilen hizmetin türü veya kategorisi. | ||
|
Açıklama
Hizmet türü, talebi ihtiyaç duyulan hizmete göre sınıflandırır. Örneğin 'Yeni donanım talebi', 'Yazılım erişimi' veya 'Parola sıfırlama'. Bu sınıflandırma genellikle kullanıcının hizmet kataloğundan seçtiği öğeye bağlıdır. Bu öznitelik, farklı hizmet türlerindeki süreçleri ve performansı karşılaştırmak için talepleri gruplandırmanızı sağlar. Hangi hizmetlerin daha karmaşık veya daha fazla kaynak gerektirdiğini gösteren 'Hizmet türü başına ortalama etkinlik sayısı' gibi temel performans göstergelerini (KPI) hesaplamak için de kullanılır. Bu analiz, belirli hizmet türlerinde süreçleri basitleştirme ve otomasyon çalışmalarına yön verebilir.
Neden önemli?
Farklı talep kategorilerindeki süreç akışlarını ve karmaşıklığı karşılaştırmanızı, standartlaştırma veya otomasyon fırsatlarını belirlemenizi sağlar.
Nereden alınır?
Yapılandırmaya bağlı olarak Freshservice’teki kayıt nesnesinin 'category', 'item' veya özel bir alanına karşılık gelir.
Örnekler
Yeni çalışan işe alıştırmaYazılım lisansı talebiVPN erişimi
|
|||
|
Öncelik
Priority
|
Hizmet talebinin Düşük, Orta, Yüksek veya Acil gibi öncelik düzeyi. | ||
|
Açıklama
Öncelik, hizmet talebinin önemini ve aciliyetini gösterir. Çoğu zaman hedef çözüm süresini ve ayrılacak kaynakları belirler. Öncelik, kurallara göre otomatik olarak veya destek uzmanları tarafından elle belirlenebilir. Process Mining analizlerinde öncelik, önemli bir inceleme boyutudur. Talepleri öncelik düzeyine göre gruplandırarak yüksek ve düşük öncelikli işlerin süreç akışlarını ve performansını karşılaştırabilirsiniz. Bu, SLA uyumluluğunu incelemek ve ilk değerlendirme aşamasında taleplere doğru ve hızlı biçimde öncelik verilip verilmediğini anlamak için gereklidir.
Neden önemli?
SLA uyumluluğunu incelemek ve taleplerin iş üzerindeki etkilerine göre değerlendirilip ele alınıp alınmadığını anlamak için önemlidir.
Nereden alınır?
Freshservice’teki kayıt nesnesinde 'priority' alanı olarak bulunur.
Örnekler
DüşükOrtaYüksekAcil
|
|||
|
Bitiş zamanı
EndTime
|
Etkinliğin tamamlandığı kesin zaman damgası. | ||
|
Açıklama
Bitiş zamanı, bir etkinliğin tamamlandığı zaman damgasını gösterir. Freshservice’teki birçok olayda başlangıç ve bitiş zamanı aynıdır; bu olaylar belirli bir anda gerçekleşir. Ancak duruma dayalı etkinliklerde bitiş zamanı, bir sonraki durum değişikliğinin zaman damgasıdır. Bu öznitelik, etkinliklerin süresini ve aralarındaki bekleme zamanlarını hesaplamak için gereklidir. Başlangıç zamanını bitiş zamanından çıkararak belirli bir görevin işlem süresini bulabilirsiniz. Böylece en çok zaman alan ve iyileştirme için öncelik verilebilecek etkinlikleri belirleyebilirsiniz.
Neden önemli?
Etkinlik sürelerini hesaplamanızı sağlar. Bu, darboğazları belirlemek ve adımların işlem sürelerini ölçmek için temel oluşturur.
Nereden alınır?
Freshservice günlüklerinde doğrudan bulunan bir alan değildir. Her hizmet talebinin olay sırasındaki bir sonraki olayın zaman damgası kullanılarak hesaplanması gerekir.
Örnekler
2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
|
|||
|
Kanal
Channel
|
Hizmet talebinin gönderildiği yöntem veya kanal. | ||
|
Açıklama
Kanal, hizmet talebinin nasıl oluşturulduğunu gösterir. Örneğin self servis portalı, e-posta, telefon veya sohbet üzerinden gönderilmiş olabilir. Bu bilgi, kullanıcı tercihlerini ve kanalların verimliliğini anlamaya yardımcı olur. Süreci kanala göre incelemek önemli sonuçlar ortaya çıkarabilir. Örneğin portal üzerinden gönderilen talepler daha eksiksiz olabilir ve e-postayla gönderilen taleplere göre daha hızlı çözülebilir. E-posta taleplerinde daha fazla yazışma gerekebilir. Bu analiz, daha verimli kanalların kullanımını artırmaya yönelik çalışmalara yol gösterebilir.
Neden önemli?
Talebin gönderildiği kanalın süreç verimliliğini, çözüm süresini veya gereken yeniden çalışma miktarını etkileyip etkilemediğini incelemenizi sağlar.
Nereden alınır?
Freshservice’teki kayıt nesnesinde 'source' alanı olarak bulunur.
Örnekler
E-postaPortalTelefonSohbet
|
|||
|
SLA ihlal edildi mi
IsSlaBreached
|
Hizmet talebinin çözüm için belirlenen SLA hedefini aşıp aşmadığını gösteren mantıksal değer. | ||
|
Açıklama
Hesaplanan bu öznitelik, hizmet talebinin SLA son tarihinden sonra kapatılıp kapatılmadığını doğru veya yanlış olarak gösterir. 'Hizmet talebi kapatıldı' ya da 'Hizmet talebi çözüldü' zaman damgası, 'SlaDueDate' ile karşılaştırılarak hesaplanır. Bu öznitelik, SLA uyumluluğu Dashboardunda analiz ve görselleştirmeyi kolaylaştırır. Hedefi karşılamayan talepleri filtreleyip bir araya getirerek genel SLA uyumluluk oranı temel performans göstergesini (KPI) hesaplayabilirsiniz. Bu değere göre gruplandırma yapmak, SLA hedefini aşan taleplerin süreç özelliklerini zamanında çözülen taleplerle karşılaştırmayı kolaylaştırır.
Neden önemli?
Hedefleri karşılamayan talepleri filtreleyip bir araya getirmek için açık bir işaret sunarak SLA uyumluluğu analizini kolaylaştırır.
Nereden alınır?
Veri dönüşümü sırasında son çözüm zaman damgası 'SlaDueDate' alanıyla karşılaştırılarak hesaplanır.
Örnekler
truefalse
|
|||
|
SLA politikası adı
SlaPolicyName
|
Talebe uygulanan Hizmet Seviyesi Anlaşması (SLA) politikasının adı. | ||
|
Açıklama
Bu öznitelik, hizmet talebi için hedef yanıt ve çözüm sürelerini belirleyen SLA politikasını gösterir. Politikalar genellikle öncelik, hizmet türü veya talep sahibinin bağlı olduğu grup gibi ölçütlere göre belirlenir. Hangi SLA politikasının uygulandığını bilmek, SLA uyumluluğu ve ihlal analizi Dashboardu için gereklidir. Tanımlanan hedeflere göre performansı doğru ölçmenizi ve en sık hangi politikaların ihlal edildiğini incelemenizi sağlar. Elde edilen sonuçlar, süreç performansının veya SLA hedeflerinin uygulanabilirliğinin yeniden değerlendirilmesine yardımcı olabilir.
Neden önemli?
Talebin hangi hizmet hedeflerine göre ölçüldüğünü belirtir ve SLA uyumluluğunu doğru raporlamak için gereklidir.
Nereden alınır?
Bu bilgi, kayıtla ilişkili SLA verilerinde yer alır. Almak için SLA ile ilgili belirli API uç noktalarını veya alanlarını sorgulamak gerekebilir.
Örnekler
Yüksek öncelikli olaylar - 4 saatStandart talepler - 3 günVIP desteği - 1 saat
|
|||
|
SLA son tarihi
SlaDueDate
|
SLA’ya göre hizmet talebinin çözülmesinin beklendiği zaman damgası. | ||
|
Açıklama
Bu öznitelik, geçerli SLA politikasında belirtilen hizmet talebi çözüm son tarihini gösterir. Talebin oluşturulma zamanı, önceliği ve SLA’da tanımlanan çalışma saatleri kullanılarak hesaplanan bir zaman damgasıdır. Gerçek zamanlı performansı izlemek ve SLA uyumluluğunu sonradan incelemek için önemli bir veri noktasıdır. Gerçek çözüm zamanını SlaDueDate ile karşılaştırarak hedefe 'Uyuldu' veya 'İhlal edildi' sonucuna varabilirsiniz. SLA uyumluluk oranı temel performans göstergesini (KPI) hesaplamanın temelini oluşturur.
Neden önemli?
Bu, çözüm için belirlenen son tarihtir. Hizmet talebinin SLA hedefine uyup uymadığını veya hedefi aşıp aşmadığını hesaplamanın temelini oluşturur.
Nereden alınır?
Freshservice’te hesaplanan bir alandır. Kayıtta 'Due by' olarak görünür ve API üzerinden alınabilir.
Örnekler
2023-10-28T17:00:00Z2023-11-01T09:00:00Z
|
|||
|
Talep sahibi
Requestor
|
Hizmet talebini gönderen kullanıcı. | ||
|
Açıklama
Bu öznitelik, hizmet talebini başlatan kişiyi, genellikle bir çalışanı, belirtir. Hizmet masasını kimin kullandığı ve neye ihtiyaç duyduğu hakkında bilgi verir. Talep sahibi veya bağlı olduğu departman, süreç akışı analizlerinde her zaman temel bir boyut olmayabilir. Yine de bu bilgilere göre analiz yapmak örüntüleri ortaya çıkarabilir. Örneğin, belirli bir departmanın sık sık eksik talep gönderdiği görülebilir; bu da o departmana yönelik bir eğitim ihtiyacına işaret eder. Müşteri deneyimine odaklanan analizler için de bu bilgi önemlidir.
Neden önemli?
Talebi başlatan kullanıcı hakkında bilgi verir; talepleri kişiye, departmana veya konuma göre incelemenizi sağlar.
Nereden alınır?
Freshservice’teki kayıt nesnesinde 'requester' alanı olarak bulunur.
Örnekler
John DoeJane SmithHizmet hesabı
|
|||
|
Talep sahibinin departmanı
RequestorDepartment
|
Talep sahibinin bağlı olduğu departman. | ||
|
Açıklama
Bu öznitelik, hizmet talebini gönderen kullanıcının bağlı olduğu departmanı belirtir. Örneğin 'Satış', 'Finans' veya 'İnsan kaynakları'. Bu bilgi genellikle sistemdeki kullanıcı profilinden alınır. Departmanlara göre süreç performansını incelemek yaygın bir ihtiyaçtır. Bu analiz, bazı departmanların daha uzun çözüm süreleriyle karşılaşıp karşılaşmadığını veya farklı süreç ihtiyaçları olup olmadığını gösterebilir. Elde edilen sonuçlar kaynak dağılımına, eğitim çalışmalarına veya departmana özel hizmetlerin oluşturulmasına yön verebilir.
Neden önemli?
Süreci iş birimine göre gruplandırarak departmana özgü sorunları veya performans farklılıklarını belirlemenizi sağlar.
Nereden alınır?
Bu bilgi, talep sahibinin profiliyle ilişkilendirilir. Freshservice’teki varsayılan 'department' alanında veya özel bir kullanıcı alanında bulunabilir.
Örnekler
FinansPazarlamaBilgi teknolojileri
|
|||
|
Yeniden atama sayısı
ReassignmentCount
|
Hizmet talebinin farklı bir destek uzmanına veya ekibe toplam kaç kez yeniden atandığı. | ||
|
Açıklama
Bu hesaplanan öznitelik, her hizmet talebi için 'Talep yeniden atandı' veya benzer etkinliklerin sayısını verir. Yeniden atama sayısının yüksek olması, ilk değerlendirmedeki sorunlara, becerilere uygun olmayan yönlendirmeye veya iş yükü dengesizliğine işaret edebilir. Bu öznitelik, 'Destek uzmanı performansı ve iş yükü dağılımı' Dashboardunu ve 'Talep başına ortalama destek uzmanı yeniden atama sayısı' temel performans göstergesini (KPI) destekler. Bu metriği inceleyerek kayıtların ekipler arasında dolaşmasına yol açan süreç sorunlarını belirleyebilirsiniz. Bu durum çözüm süresini uzatır ve hem destek uzmanlarını hem de talep sahiplerini zorlar.
Neden önemli?
Yönlendirme verimsizliğini ve süreçteki aksaklıkları ölçer. Sayının yüksek olması, ilk değerlendirmede veya destek uzmanlarının iş yükünde sorunlar olduğunu ve gecikmeler yaşandığını gösterir.
Nereden alınır?
Veri dönüşümü sırasında her 'ServiceRequestId' için belirli atama değişikliği etkinlikleri sayılarak hesaplanır.
Örnekler
013
|
|||
|
Yeniden çalışma var mı
IsRework
|
Talepte yeniden çalışma etkinlikleri olup olmadığını gösteren mantıksal değer. | ||
|
Açıklama
Bu hesaplanan işaret, hizmet talebinde yeniden çalışmaya işaret eden belirli etkinlikler gerçekleştiğinde doğru olarak ayarlanır. Örneğin, çözümden sonra talebin yeniden açılması ('Hizmet talebi yeniden açıldı'), birden fazla kez yeniden atanması veya kullanıcıdan tekrar tekrar bilgi istenmesi ('Talep sahibinden bilgi istendi') bu kapsamdadır. Bu öznitelik, süreç verimsizliklerini incelemeyi kolaylaştırır. Yeniden çalışma içeren vakaları filtreleyerek süreç haritalarını ve çevrim sürelerini sorunsuz vakalarla karşılaştırabilirsiniz. Böylece 'Hizmet talebinde yeniden çalışma analizi' Dashboardunu destekler ve verimsiz devir teslimlerin ya da başlangıçta eksik bilgi alınmasının etkisini ölçmenize yardımcı olur.
Neden önemli?
Verimsiz döngüler veya tekrarlanan adımlar içeren vakaları işaretleyip incelemenin kolay bir yolunu sunar ve düşük kalite maliyetini ölçmeye yardımcı olur.
Nereden alınır?
Veri dönüşümü sırasında her 'ServiceRequestId' için etkinlik sırasına iş kuralları uygulanarak hesaplanır.
Örnekler
truefalse
|
|||
Hizmet talebi yönetimi etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Harici tedarikçi sürece dahil oldu
|
Bu etkinlik, bir talebin çözüm için harici bir tedarikçiye veya üçüncü tarafa devredildiği anı gösterir. Durumun 'Tedarikçi bekleniyor' veya 'Üçüncü taraf bekleniyor' gibi belirli bir değere geçmesinden çıkarılır. | ||
|
Neden önemli?
Tedarikçinin sürece dahil olması önemli gecikmelere yol açabilir. Bu etkinliği izlemek, tedarikçi performansını ve bunun hizmet talebinin toplam çevrim süresine etkisini ölçmek için gereklidir.
Nereden alınır?
Talebin durum değişikliği geçmişinden çıkarılır. Harici tedarikçilere bağımlılığı izlemek üzere yapılandırılmış belirli bir durumu arayın.
Kaydedin
Talep durumu alanının üçüncü bir tarafın beklendiğini belirten bir değere geçtiği anı tespit edin.
Olay türü
inferred
|
|||
|
Hizmet talebi çözüldü
|
Bu önemli aşama, uzmanın çözüm sunduğu ve işi tamamlanmış saydığı noktayı gösterir. Talep durumunun 'Çözüldü' olarak değişmesinden çıkarılır. | ||
|
Neden önemli?
Bu etkinlik, aktif çalışma aşamasının sonunu gösterir. Bu noktaya kadar geçen süre, uzman ve süreç verimliliğinin temel ölçütlerinden biridir ve SLA hesaplamalarının temelini oluşturur.
Nereden alınır?
Talebin durum değişikliği geçmişinden çıkarılır. Durumun ilk kez 'Çözüldü' olarak ayarlandığı zaman damgasına karşılık gelir.
Kaydedin
Talep durumu ilk kez 'Çözüldü' olarak değiştiğinde zaman damgasını kaydedin.
Olay türü
inferred
|
|||
|
Hizmet talebi kapatıldı
|
Bu son etkinlik, hizmet talebi yaşam döngüsünün tamamlandığını gösterir. Talep yeniden açılmadan 'Çözüldü' durumunda belirli bir süre kaldıktan sonra genellikle otomatik olarak gerçekleşir. | ||
|
Neden önemli?
Bu olay, süreç örneğinin kesin olarak sona erdiğini gösterir. 'Resolved' ile 'Closed' arasındaki süre, talep sahibinin onay vermesi için tanınan süreyi ifade eder.
Nereden alınır?
Talebin durum değişikliği geçmişinden çıkarılır. Durumun 'Closed' olarak değiştiği zaman damgasına karşılık gelir.
Kaydedin
Talep durumu 'Closed' olduğunda bu zaman damgasını kaydedin.
Olay türü
inferred
|
|||
|
Hizmet talebi oluşturuldu
|
Bu etkinlik, Freshservice’te yeni bir talebin resmî olarak kaydedilmesiyle hizmet talebi yaşam döngüsünün başladığını gösterir. Hizmet kataloğu, e-posta veya başka bir kanal üzerinden yeni bir kayıt oluşturulduğunda bu olay açıkça kaydedilir ve benzersiz bir Hizmet Talebi Kimliği atanır. | ||
|
Neden önemli?
Bu, sürecin temel başlangıç olayıdır. Genel çevrim sürelerini ölçmek ve ilk aşamadaki gecikmeleri belirlemek için bu etkinlikten diğer etkinliklere kadar geçen süreyi analiz etmek gerekir.
Nereden alınır?
Bu olay Freshservice’te açıkça kaydedilir. Genellikle talebin oluşturulma zaman damgasına karşılık gelir ve talebin etkinlik günlüğünde veya denetim izinde bulunabilir.
Kaydedin
Freshservice talepleri verilerindeki talep oluşturma zaman damgasını kullanın.
Olay türü
explicit
|
|||
|
SLA hedefi aşıldı
|
Hizmet talebinin çözüm süresi, tanımlanan Hizmet Seviyesi Anlaşması (SLA) hedefini aştığında gerçekleşen hesaplanmış bir olaydır. Doğrudan bir sistem olayı değildir; çözüm süresiyle SLA son tarihi karşılaştırılarak belirlenir. | ||
|
Neden önemli?
Bu olay, hizmet performansını taahhütlerle doğrudan karşılaştırır ve yönetim için temel bir KPI’dır. Hangi talep türlerinin veya önceliklerin hedefi kaçırma riski taşıdığını belirlemeye yardımcı olur.
Nereden alınır?
'Çözüldü' zaman damgası ile 'SLA son tarihi' zaman damgası karşılaştırılarak hesaplanır. Çözüm daha geç gerçekleşirse bu olay tetiklenir.
Kaydedin
Çözüm zaman damgasını SLA son tarihi zaman damgasıyla karşılaştırın. resolved_at > sla_due_by ise bu olayı oluşturun.
Olay türü
calculated
|
|||
|
Talep uzmana atandı
|
Hizmet talebinin işlenmek üzere belirli bir uzmana atandığı noktayı gösterir. Bu önemli aşama, talebin 'Atanan uzman' veya 'Sahip' alanındaki değişiklikler izlenerek belirlenir. | ||
|
Neden önemli?
Bu etkinlik, uzmanların iş yükünü analiz etmek ve atama sürecindeki darboğazları belirlemek için önemlidir. Talebin oluşturulmasıyla atanması arasında geçen süre, temel bir performans göstergesidir.
Nereden alınır?
Talebin etkinlik günlüğündeki veya alan denetim izindeki 'Uzman' ya da 'Atanan kişi' alanı değişiklikleri izlenerek belirlenir.
Kaydedin
'Atanan uzman' alanına ilk kez değer girildiği veya alanın değeri değiştiği andaki zaman damgasını kaydedin.
Olay türü
inferred
|
|||
|
Çözüm talep sahibi tarafından onaylandı
|
Bu etkinlik, talep sahibinin sunulan çözümün yeterli olduğunu açıkça onaylamasını ifade eder. Talep kapatılmadan önce verilen olumlu bir anket yanıtından veya belirli bir yorumdan çıkarılabilir. | ||
|
Neden önemli?
Onay, çözümün kalitesi hakkında doğrudan geri bildirim sağlar. Onay oranının düşük olması, talepler yeniden açılmasa bile çözümlerin kullanıcı ihtiyaçlarını tam olarak karşılamadığına işaret edebilir.
Nereden alınır?
Bu bilgiyi doğrudan kaydetmek zordur ve özel yapılandırma gerektirebilir. Talebe bağlı müşteri memnuniyeti anketi yanıtından veya eklenen belirli bir etiketten çıkarılabilir.
Kaydedin
Çözümden sonra eklenen memnuniyet anketleri veya etiketler gibi ilişkili verilerin analiz edilmesi gerekir.
Olay türü
inferred
|
|||
|
Hizmet talebi yeniden açıldı
|
Talep sahibi, sorun 'Çözüldü' olarak işaretlendikten sonra devam ettiğini bildirdiğinde ve talep yeniden açık duruma geçtiğinde gerçekleşir. Durumun 'Çözüldü' değerinden yeniden 'Açık' veya 'Devam ediyor' değerine geçmesinden çıkarılır. | ||
|
Neden önemli?
Yeniden açılan talepler, ilk temasta çözüm oranının düşük ve müşteri memnuniyetsizliğinin yüksek olduğuna güçlü biçimde işaret eder. Çözüm kalitesini artırmak için bu yeniden çalışma döngüsünü izlemek önemlidir.
Nereden alınır?
Etkinlik günlüğündeki talep durum değişikliği geçmişinden çıkarılır. 'Çözüldü' durumundan 'Açık' durumuna doğrudan geçiştir.
Kaydedin
Durumun çözüldü değerinden açık değerine geçtiğini tespit edin.
Olay türü
inferred
|
|||
|
İç inceleme yapıldı
|
Önerilen bir çözümün veya talebin karşılanmasının devam etmeden önce iç inceleme ya da onay gerektirdiğini gösterir. Durumun 'Onay bekleniyor' veya 'İç inceleme' gibi bir değere geçmesinden çıkarılır. | ||
|
Neden önemli?
Özellikle karmaşık veya etkisi yüksek hizmet taleplerinde iç incelemeler darboğazlara yol açabilir. Bu sürenin ölçülmesi, onay iş akışlarını kolaylaştırmaya yardımcı olur.
Nereden alınır?
Talebin durum değişikliği geçmişinden çıkarılır. İş akışında 'İç onay bekleniyor' gibi belirli bir durumun kullanılması gerekir.
Kaydedin
Talep durumu alanının iç inceleme veya onay gerektiğini belirten bir değere geçtiği anı tespit edin.
Olay türü
inferred
|
|||
|
Not eklendi
|
Bir uzmanın veya talep sahibinin hizmet talebine eklediği herkese açık ya da özel notları ifade eder. Talebin konuşma veya etkinlik günlüğünde açıkça kaydedilen bir olaydır. | ||
|
Neden önemli?
Notların sıklığını ve zamanlamasını analiz etmek; iletişim örüntülerini, iş birliğinin verimliliğini ve süreçteki belirsizlik noktalarını ortaya çıkarabilir.
Nereden alınır?
Freshservice’te talebin konuşma geçmişine açıkça kaydedilir. Her notun bir zaman damgası ve yazarı vardır.
Kaydedin
Talebin konuşma veya yorum günlüğündeki her kaydı çıkarın.
Olay türü
explicit
|
|||
|
Talebe öncelik verildi
|
Hizmet talebine Düşük, Orta veya Yüksek gibi bir öncelik düzeyi atandığında bu etkinlik gerçekleşir. Talep geçmişindeki 'Öncelik' alanı değişikliği tespit edilerek belirlenir. | ||
|
Neden önemli?
Önceliklendirme, kaynakları dağıtmak ve SLA hedeflerine ulaşmak için önemlidir. Bu etkinliği analiz ederek taleplerin doğru ve zamanında değerlendirildiğini doğrulayabilirsiniz.
Nereden alınır?
Freshservice’te talebin alan değişikliği geçmişinden çıkarılır. 'Öncelik' alanındaki güncellemeleri bulun ve değişikliğin zaman damgasını kaydedin.
Kaydedin
'Öncelik' alanının boş değerden veya önceki değerinden farklılaştığını tespit edin ve zaman damgasını kaydedin.
Olay türü
inferred
|
|||
|
Talep sahibi bilgi sağladı
|
Talep sahibi gerekli bilgileri sağladığında ve uzman çalışmaya devam edebildiğinde gerçekleşir. Genellikle talep durumunun 'Beklemede' durumundan yeniden 'Açık' durumuna otomatik olarak geçmesinden çıkarılır. | ||
|
Neden önemli?
Bu etkinlik, bilgi talebi döngüsünü tamamlar. Bilginin istenmesiyle sağlanması arasında geçen süre, analiz edilip iyileştirilmesi gereken önemli bir bekleme süresidir.
Nereden alınır?
Talep durumunun 'Beklemede' durumundan yeniden 'Açık' veya 'Devam ediyor' durumuna geçmesinden çıkarılır. Bu geçişi genellikle talep sahibinin yanıtı başlatır.
Kaydedin
Talep durumunun beklemede durumundan açık duruma geçtiği anı tespit edin.
Olay türü
inferred
|
|||
|
Talep sahibinden bilgi istendi
|
Atanan uzmanın talep sahibinden ek bilgi istediği ve sürecin beklemeye alındığı noktayı ifade eder. Talep durumunun 'Beklemede' veya 'Müşteri bekleniyor' olarak değişmesinden çıkarılır. | ||
|
Neden önemli?
Bu etkinlik, gecikme ve yeniden çalışmanın yaygın bir nedenini gösterir. Ne sıklıkta gerçekleştiğini analiz etmek, talep Templatelerini ve ilk veri toplama sürecini iyileştirme fırsatlarını belirlemeye yardımcı olur.
Nereden alınır?
Talebin durum değişikliği geçmişinden çıkarılır. 'Müşteri yanıtı bekleniyor' veya 'Bilgi bekleniyor' gibi bir duruma geçişi arayın.
Kaydedin
Talep durumu alanının kullanıcı girdisi beklendiğini belirten bir değere geçtiği anı tespit edin.
Olay türü
inferred
|
|||
|
Talep sınıflandırıldı
|
Yeni oluşturulan bir hizmet talebinin ilk değerlendirmesini ve kategorilere ayrılmasını ifade eder. Genellikle önceliğin ilk kez belirlenmesinden veya talebin bir gruba atanmasından çıkarılır. Bu, talebin incelendiğini ve kuyruğa alındığını gösterir. | ||
|
Neden önemli?
Sınıflandırma aşamasını izlemek, ilk yanıt ekibinin verimliliğini ölçmeye yardımcı olur. Bu aşamadaki gecikmeler, toplam çözüm süresini ve SLA uyumluluğunu önemli ölçüde etkileyebilir.
Nereden alınır?
Etkinlik günlüğündeki kayıtlardan çıkarılır. Talep oluşturulduktan sonra gerçekleşen ilk 'Öncelik belirlendi' veya 'Grup atandı' olayının zaman damgasıyla tespit edilebilir.
Kaydedin
Öncelik alanındaki veya atama grubu alanındaki ilk değişikliğin zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep yeniden atandı
|
Bu etkinlik, ilk atamadan sonra atanan uzmanın veya grubun değiştiği her durumu kaydeder. 'Atanan uzman' ya da 'Atanan grup' alanlarında sonraki güncellemeler tespit edilerek belirlenir. | ||
|
Neden önemli?
Sık yeniden atamalar; ilk sınıflandırmada, uzmanların becerilerinin eşleştirilmesinde veya iş yükü dengesinde sorunlara işaret edebilir. Bu etkinlik, Uzman Yeniden Atama Sayısı KPI’ı ve yeniden çalışma analizi için önemlidir.
Nereden alınır?
Talebin alan değişikliği geçmişinden çıkarılır. 'Atanan uzman' veya 'Atanan grup' alanı ilk değeri belirlendikten sonra her güncellendiğinde bu olay kaydedilir.
Kaydedin
İlk atamadan sonra 'Atanan uzman' veya 'Atanan grup' alanındaki değişiklikleri tespit edin.
Olay türü
inferred
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Verilerinizi hazırlayarak hizmet talebi yönetimi sürecinizi optimize etmek için ilk adımı atın. Hizmet sunumunuzu iyileştirirken size destek oluyoruz.
Freshservice’te hizmet taleplerini bugün daha verimli yönetin
Yavaş talep karşılamaya ve kullanıcı memnuniyetsizliğine son verin, %70 otomasyona ulaşın.
Kredi kartı gerekmez. Kurulum birkaç dakika sürer.