Hizmet İsteği Yönetimi Veri Şablonunuz
Hizmet İsteği Yönetimi Veri Şablonunuz
- Toplanması önerilen öznitelikler
- İzlenecek önemli etkinlikler
- Veri çıkarma rehberi
Hizmet Talebi Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Faaliyet adı
ActivityName
|
Bir Service Request için belirli bir zamanda gerçekleşen olayın veya görevin adı. | ||
|
Açıklama
Faaliyet adı, Service Request yaşam döngüsündeki belirli bir adımı veya olayı tanımlar. Bu faaliyetler sistem denetim günlüklerinden, durum değişikliklerinden veya kullanıcıların gerçekleştirdiği 'Request Assigned to Agent', 'Note Added' ya da 'Service Request Resolved' gibi belirli işlemlerden çıkarılır. Bu öznitelik, Service Request akışını görsel olarak gösteren süreç haritasını oluşturmak için önemlidir. Kuruluşlar farklı faaliyetlerin sırasını ve sıklığını analiz ederek gerçek süreci anlayabilir, adımlar arasındaki darboğazları belirleyebilir, faaliyet sürelerini ölçebilir ve uyumsuz ya da verimsiz süreç varyantlarını tespit edebilir.
Neden önemli?
Bu öznitelik, süreç haritasındaki adımları tanımlar ve Service Request Workflow sürecinin görselleştirilmesini ve analiz edilmesini sağlar.
Nereden alınır?
Freshservice içinde bir ticket ile ilişkilendirilmiş 'activities' veya 'audits' verilerinden oluşturulur. Bu işlem, sistem olaylarını iş birimleri için anlaşılır faaliyet adlarına eşlemek üzere dönüşüm mantığı gerektirebilir.
Örnekler
Service Request oluşturulduTalep temsilciye atandıService Request çözüldüService Request kapatıldı
|
|||
|
Hizmet talebi ID'si
ServiceRequestId
|
Her Service Request için benzersiz tanımlayıcı. | ||
|
Açıklama
Service Request ID, Freshservice sistemine kaydedilen her yeni Service Request için 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 içinde bu ID temel bir unsurdur ve Case ID olarak kullanılır. Durum değişiklikleri, temsilci atamaları ve notlar gibi ilgili tüm olaylar bu tanımlayıcı kullanılarak birbirine bağlanır. Her Service Request ID'nin yolculuğunu analiz etmek, sürecin uçtan uca görünümünü oluşturmayı, yaygın yolları belirlemeyi ve tek tek vakaları etkileyen sapmaları veya darboğazları tespit etmeyi sağlar.
Neden önemli?
Bu, ilgili tüm olayları birbirine bağlayan temel Case ID'dir ve tek bir Service Request'in uçtan uca yolculuğunun izlenmesini sağlar.
Nereden alınır?
Freshservice içindeki ticket nesnesinin birincil alanıdır. Kullanıcı arayüzünde görünür ve Freshservice API üzerinden kullanılabilir.
Örnekler
SR-12943SR-13501SR-14011
|
|||
|
Olay zamanı
EventTime
|
Faaliyetin gerçekleştiği kesin zaman damgası. | ||
|
Açıklama
Olay zamanı, belirli bir faaliyetin bir Service Request için kaydedildiği tarih ve saati gösterir. Bu zaman damgası, olayları doğru sıraya koymak ve aralarındaki süreleri hesaplamak için temel oluşturur. Process Mining içinde bu öznitelik, her vaka için faaliyetleri sıralamak ve zamana dayalı tüm analizleri oluşturmak amacıyla kullanılır. Çevrim sürelerini, faaliyetler arasındaki bekleme sürelerini ve service level agreement (SLA) uyumluluğunu hesaplamaya yardımcı olur. Doğru zaman damgaları, darboğazları belirlemek ve süreç performansını anlamak için önemlidir.
Neden önemli?
Bu zaman damgası olayları kronolojik olarak sıralar ve çevrim süresi ile darboğaz tespiti dahil tüm performans analizlerinin temelini oluşturur.
Nereden alınır?
Freshservice içindeki bir faaliyet 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
|
Verilerin hangi sistemden çıkarıldığını belirtir. | ||
|
Açıklama
Bu öznitelik, süreç verilerinin kaynak sistemini belirtir. Bu örnekte kaynak sistem Freshservice'tir. Birden fazla sistemden alınan verilerin bütünsel bir süreç görünümü oluşturmak üzere birleştirildiği ortamlarda özellikle faydalıdır. Tek sistemli bir analizde gereksiz görünebilse de gelecekte ölçeklenebilirlik ve veri yönetişimi için bu özniteliğin eklenmesi iyi bir uygulamadır. Verinin kaynağını netleştirir ve veri entegrasyonu hatlarının yönetilmesine yardımcı olur.
Neden önemli?
Veri kaynağının ve izlenebilirliğin korunmasını sağlar. Bu, birden fazla sistemden veri birleştirilirken veya veri yönetişimi amacıyla önemlidir.
Nereden alınır?
Genellikle veri çıkarma ve dönüştürme (ETL) sürecinde eklenen statik bir değerdir.
Örnekler
FreshserviceFreshservice-API-v2
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Verilerin kaynak sistemden en son ne zaman yenilendiğini gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, Veri Setinin Freshservice sisteminden en son çıkarıldığı veya güncellendiği tarih ve saati kaydeder. Analiz edilen verilerin güncelliği hakkında bağlam sağlar. Her süreç analizinde verilerin güncelliğini bilmek önemlidir. Bu zaman damgası, kullanıcıların en güncel bilgilere bakıp bakmadığını anlamasına yardımcı olur. Zamanında operasyonel kararlar almak ve analizden elde edilen içgörülere güvenmek için bu bilgi gereklidir.
Neden önemli?
Kullanıcılara verilerin güncelliği hakkında bilgi verir ve 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) sürecinde oluşturulur ve Veri Setine eklenir.
Örnekler
2024-05-21T02:00:00Z2024-05-20T02:00:00Z
|
|||
|
Atanan ekip
AssignedTeam
|
Service Request'i işlemek üzere atanan destek ekibi veya grup. | ||
|
Açıklama
Bu öznitelik, Service Request'ten sorumlu olan 'IT Support Level 2' veya 'Hardware Procurement' gibi işlevsel grubu ya da ekibi belirtir. Bir talep, bireysel bir temsilci tarafından işleme alınmadan önce bir ekibe atanabilir. Atanan ekibe göre analiz yapmak, ekip düzeyindeki performansı ve iş yükünü anlamaya, belirli işlev alanlarına özgü darboğazları belirlemeye 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 önemlidir.
Neden önemli?
Ekip veya grup düzeyinde performans ve iş yükü analizi yapılmasını sağlar. Bu, kaynak yönetimi ve işlevsel darboğazların belirlenmesi için önemlidir.
Nereden alınır?
Freshservice içindeki ticket nesnesinde 'group' alanı olarak bulunur.
Örnekler
Hizmet MasasıAğ OperasyonlarıUygulama Desteği
|
|||
|
Atanan temsilci
AssignedAgent
|
Şu anda Service Request'e atanmış bireysel temsilcinin adı. | ||
|
Açıklama
Bu öznitelik, belirli bir zamanda Service Request'i işlemekten sorumlu destek temsilcisini tanımlar. Bir talebin yaşam döngüsü boyunca temsilci atamaları değişebilir. Atanan temsilciyi analiz etmek, temsilci performansını ve iş yükü dağılımını anlamak için önemlidir. Temsilci başına ortalama çözüm süresi, aktif talep sayısı ve yeniden atama oranı gibi KPI'ların hesaplanmasını sağlar. Böylece yüksek performans gösteren temsilciler, ek eğitime ihtiyaç duyabilecek temsilciler ve iş yükü dağılımındaki dengesizlikler belirlenebilir.
Neden önemli?
Temsilci iş yükünü ve performansını, ayrıca yeniden atamaların çözüm sürelerine etkisini analiz etmeyi sağlar.
Nereden alınır?
Freshservice içindeki ticket nesnesinde 'agent' veya 'responder' alanı olarak bulunur.
Örnekler
Alice JohnsonRobert SmithAtanmadı
|
|||
|
Durum
Status
|
Service Request'in yaşam döngüsündeki mevcut durumu. | ||
|
Açıklama
Durum alanı, Service Request'in belirli bir zamandaki durumunu, örneğin 'Open', 'Pending', 'Resolved' veya 'Closed' değerlerini gösterir. Durum değişiklikleri, Process Mining için çoğu zaman temel faaliyet kaynağıdır. Durumu analiz etmek, süreç akışına bağlam sağlar ve taleplerin belirli durumlarda ne kadar süre kaldığını anlamaya yardımcı olur. Örneğin, 'Pending' durumunda uzun süre kalınması, talep sahibinden bilgi veya harici tedarikçiden girdi beklenmesinden kaynaklanan bir darboğaza işaret edebilir. Bu, farklı süreç aşamalarının başlangıç ve bitiş noktalarını tanımlamak için önemli bir özniteliktir.
Neden önemli?
Her olay için önemli bağlam sağlar ve gecikmeleri belirlemek üzere 'Open' veya 'Pending' gibi farklı durumlarda geçirilen süreyi ölçmeye yardımcı olur.
Nereden alınır?
Freshservice içindeki ticket nesnesinde 'status' alanı olarak bulunur.
Örnekler
AçıkBeklemedeÇözüldüKapatıldı
|
|||
|
Hizmet türü
ServiceType
|
Talep edilen hizmetin belirli türü veya kategorisi. | ||
|
Açıklama
Hizmet türü, talebi 'New Hardware Request', 'Software Access' veya 'Password Reset' gibi ihtiyaç duyulan hizmet türüne göre sınıflandırır. Bu değer çoğu zaman kullanıcının seçtiği servis kataloğu öğesiyle ilişkilidir. Bu öznitelik, farklı hizmet türlerindeki süreçleri ve performansı karşılaştırmak üzere Service Request'leri segmentlere ayırmayı sağlar. 'Average Activity Count per Service Type' gibi KPI'ları hesaplamak için önemlidir. Bu analiz, hangi hizmetlerin daha karmaşık veya daha fazla kaynak gerektirdiğini belirlemeye yardımcı olur ve belirli hizmet türleri için süreç sadeleş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ırmayı sağlar. Böylece standardizasyon veya otomasyon için uygun alanlar belirlenebilir.
Nereden alınır?
Yapılandırmaya bağlı olarak Freshservice içindeki ticket nesnesinde genellikle 'category', 'item' veya özel bir alana karşılık gelir.
Örnekler
Yeni çalışan işe alımıYazılım lisansı talebiVPN erişimi
|
|||
|
Öncelik
Priority
|
Low, Medium, High veya Urgent gibi Service Request öncelik düzeyi. | ||
|
Açıklama
Öncelik, bir Service Request'in önemini ve aciliyetini gösterir. Bu değer genellikle hedef çözüm süresini ve ayrılan kaynakları belirler. Öncelik, kurallara göre otomatik olarak veya temsilciler tarafından manuel olarak belirlenebilir. Process Mining içinde Öncelik, analiz için önemli bir boyuttur. Talepleri segmentlere ayırarak yüksek öncelikli ve düşük öncelikli öğelerin süreç akışlarını ve performansını karşılaştırmak için kullanılır. Bu, SLA uyumluluğu analizinde ve önceliklendirmenin ön değerlendirme aşamasında etkili ve hızlı yapılıp yapılmadığını anlamada önemlidir.
Neden önemli?
SLA uyumluluğu analizi ve taleplerin iş etkilerine göre ön değerlendirmeden geçirilip işlenip işlenmediğini anlamak için önemlidir.
Nereden alınır?
Freshservice içindeki ticket 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 tamamlanma zaman damgasını gösterir. Freshservice'teki birçok olayda başlangıç ve bitiş zamanları aynıdır; bu nedenle bunlar belirli bir andaki olaylardır. 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. StartTime değerinin EndTime değerinden çıkarılmasıyla belirli bir görevin işlem süresi belirlenebilir. Bu bilgi, en fazla zaman alan ve optimizasyon için öncelikli aday olan etkinlikleri belirlemek açısından önemlidir.
Neden önemli?
Etkinlik sürelerinin hesaplanmasını sağlar. Bu, darboğazları belirlemek ve tek tek 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. Belirli bir hizmet talebi için dizideki sonraki olayın zaman damgası alınarak türetilmesi gerekir.
Örnekler
2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
|
|||
|
Kanal
Channel
|
Service Request'in gönderildiği yöntem veya kanal. | ||
|
Açıklama
Kanal, Service Request'in nasıl oluşturulduğunu gösterir. Örneğin talep self servis portalı, e-posta, telefon görüşmesi veya sohbet üzerinden oluşturulmuş olabilir. Bu bilgi, kullanıcı tercihlerini ve kanal verimliliğini anlamaya yardımcı olur. Süreci kanala göre analiz etmek önemli içgörüler sağlayabilir. Örneğin portal üzerinden gönderilen talepler, e-posta yoluyla gönderilen ve daha fazla karşılıklı iletişim gerektirebilen taleplere göre daha eksiksiz olabilir ve daha hızlı çözülebilir. Bu analiz, daha verimli kanalların kullanımını artırma çalışmalarına yön verebilir.
Neden önemli?
Gönderim kanalının süreç verimliliğini, çözüm süresini veya gereken yeniden iş miktarını etkileyip etkilemediğini analiz etmeye yardımcı olur.
Nereden alınır?
Freshservice içindeki ticket nesnesinde 'source' alanı olarak bulunur.
Örnekler
E-postaPortalTelefonSohbet
|
|||
|
SLA ihlal edildi mi
IsSlaBreached
|
Hizmet talebinin çözüm SLA hedefini aşıp aşmadığını belirten boolean işareti. | ||
|
Açıklama
Bu hesaplanmış öznitelik, hizmet isteğinin SLA son tarihinden sonra kapatılıp kapatılmadığını gösteren basit bir doğru veya yanlış işaretidir. Bu öznitelik, SLA uyumluluğu Dashboardu için analizi ve görselleştirmeyi kolaylaştırır. Genel SLA uyumluluk oranı KPI’ını hesaplamak üzere kolayca filtreleme ve toplama yapmanızı sağlar. Bu işarete göre bölümlere ayırma, süresi aşılmış isteklerle zamanında çözülen isteklerin süreç özelliklerini hızlıca ayırıp analiz etmenize yardımcı olur.
Neden önemli?
Hedeflerini karşılamayan talepleri filtrelemek ve toplulaştırmak için net bir işaret sağlayarak SLA uyumluluk analizini kolaylaştırır.
Nereden alınır?
Veri dönüşümü sırasında son çözüm zaman damgasının 'SlaDueDate' alanıyla karşılaştırılmasıyla hesaplanan bir alandır.
Örnekler
truefalse
|
|||
|
SLA politikası adı
SlaPolicyName
|
Talebe uygulanan Service Level Agreement (SLA) politikasının adı. | ||
|
Açıklama
Bu öznitelik, Service Request için hedef yanıt ve çözüm sürelerini belirleyen SLA politikasını tanımlar. Politikalar genellikle öncelik, hizmet türü veya talep sahibi grubu gibi etkenlere göre belirlenir. Hangi SLA politikasının uygulandığını bilmek, SLA Compliance & Breach Analysis Dashboard için önemlidir. Tanımlanan hedeflere göre performansın doğru ölçülmesini ve hangi politikaların en sık ihlal edildiğinin analiz edilmesini sağlar. Bu analiz, süreç performansının veya SLA hedeflerinin uygulanabilirliğinin yeniden değerlendirilmesine yol açabilir.
Neden önemli?
Talebin hangi hizmet hedeflerine göre ölçüldüğünü belirtir ve doğru SLA uyumluluğu raporlaması için önemlidir.
Nereden alınır?
Bu bilgi, bir ticket ile ilişkilendirilmiş SLA verilerinin parçasıdır. Belirli SLA ile ilgili API uç noktalarının veya alanlarının sorgulanması gerekebilir.
Örnekler
Yüksek öncelikli olaylar - 4 saatStandart talepler - 3 günVIP desteği - 1 saat
|
|||
|
SLA Son Tarihi
SlaDueDate
|
Hizmet talebinin SLA'sına göre çözülmesinin beklendiği zaman damgası. | ||
|
Açıklama
Bu öznitelik, geçerli SLA politikasında tanımlanan hizmet talebi çözüm son tarihini belirtir. Talebin oluşturulma zamanı, önceliği ve SLA'da tanımlanan çalışma saatlerine göre hesaplanan bir zaman damgasıdır. Gerçek zamanlı performansı izlemek ve geçmişe dönük SLA uyumluluk analizi yapmak için önemli bir veri noktasıdır. Gerçek çözüm zamanı SlaDueDate ile karşılaştırılarak talebin SLA'yı karşılayıp karşılamadığı veya ihlal edip etmediği belirlenebilir. SLA Uyumluluk Oranı KPI'sının hesaplanması için temel oluşturur.
Neden önemli?
Bu, çözüm için hedef son tarihtir ve bir hizmet talebinin SLA'sını karşılayıp karşılamadığını veya ihlal edip etmediğini hesaplamanın temelini oluşturur.
Nereden alınır?
Bu, Freshservice içindeki hesaplanan bir alandır ve ticket üzerinde 'Due by' olarak görünür. API üzerinden kullanılabilir.
Örnekler
2023-10-28T17:00:00Z2023-11-01T09:00:00Z
|
|||
|
Talep sahibi
Requestor
|
Service Request'i gönderen kullanıcı. | ||
|
Açıklama
Bu öznitelik, genellikle bir çalışan olan ve Service Request'i başlatan kişiyi tanımlar. Hizmet masasını kimin kullandığı ve ihtiyaçlarının neler olduğu hakkında bağlam sağlar. Süreç akışı analizinde her zaman birincil boyut olarak kullanılmasa da talep sahibine veya bağlı olduğu departmana göre analiz yapmak çeşitli kalıpları ortaya çıkarabilir. Örneğin belirli bir departmanın sık sık eksik talepler gönderdiği görülebilir. Bu da hedefli bir eğitim ihtiyacına işaret eder. Müşteri deneyimine odaklanan analizler için de önemlidir.
Neden önemli?
Talebi başlatan kullanıcı hakkında bağlam sağlar ve taleplerin kişi, departman veya konuma göre analiz edilmesini mümkün kılar.
Nereden alınır?
Freshservice içindeki ticket nesnesinde 'requester' alanı olarak bulunur.
Örnekler
John DoeJane SmithHizmet hesabı
|
|||
|
Talep sahibi departmanı
RequestorDepartment
|
Talep sahibinin bağlı olduğu departman. | ||
|
Açıklama
Bu öznitelik, Service Request'i gönderen kullanıcının 'Sales', 'Finance' veya 'Human Resources' gibi kurumsal departmanını belirtir. Bu bilgi genellikle sistemdeki kullanıcı profilinden alınır. Süreç performansını departmana göre analiz etmek yaygın bir gereksinimdir. Belirli departmanların daha uzun çözüm süreleri yaşayıp yaşamadığını veya kendilerine özgü süreç ihtiyaçları bulunup bulunmadığını ortaya çıkarabilir. Bu içgörü, kaynak dağılımına, eğitim çalışmalarına veya departmana özel hizmetlerin oluşturulmasına yön verebilir.
Neden önemli?
Sürecin iş birimine göre segmentlere ayrılmasını sağlar ve departmana özgü sorunların veya performans farklılıklarının belirlenmesine yardımcı olur.
Nereden alınır?
Bu bilgi talep sahibinin profili üzerinden ilişkilendirilir. Freshservice içinde varsayılan bir 'department' alanında veya özel bir kullanıcı alanında bulunabilir.
Örnekler
FinansPazarlamaBilgi Teknolojileri
|
|||
|
Yeniden atama sayısı
ReassignmentCount
|
Bir hizmet talebinin farklı bir temsilciye veya ekibe kaç kez yeniden atandığını gösteren toplam sayı. | ||
|
Açıklama
Bu, her hizmet isteği için Bu öznitelik, "Temsilci performansı ve iş yükü dağılımı" Dashboardunu ve "İstek başına ortalama temsilci yeniden atama sayısı" KPI’ını doğrudan destekler. Bu metriği analiz etmek, taleplerin temsilciler arasında dolaşmasına yol açan süreç zayıflıklarını belirlemenize yardımcı olur. Bu durum çözüm süresini uzatır ve hem temsilcileri hem de talep sahiplerini zorlar.
Neden önemli?
Yönlendirme verimsizliğini ve süreçteki sürtünmeyi ölçer. Yüksek değer, ilk sınıflandırma veya temsilci iş yüküyle ilgili sorunlara ve buna bağlı gecikmelere işaret eder.
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 işleme var mı
IsRework
|
Talebin yeniden işleme etkinlikleri içerip içermediğini belirten boolean işareti. | ||
|
Açıklama
Bu hesaplanmış işaret, bir hizmet isteği yeniden çalışmaya işaret eden belirli etkinliklerden geçtiğinde doğru olarak ayarlanır. Örnekler arasında çözümden sonra yeniden açılma ("Service Request Reopened"), birden fazla yeniden atama veya kullanıcıdan tekrar tekrar bilgi istenmesi ("Information Requested from Requestor") bulunur. Bu öznitelik, süreç verimsizliklerinin analizini kolaylaştırır. Yeniden çalışma içeren vakaları ayırmak ve bunların süreç haritalarıyla çevrim sürelerini sorunsuz vakalarla karşılaştırmak için kolayca filtreleme yapabilirsiniz. Bu özellik, hizmet isteği yeniden işleme analizi Dashboardunu doğrudan destekler ve verimsiz devir teslimlerin veya 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 analiz etmenin kolay bir yolunu sunar ve düşük kalitenin maliyetini ölçmenize yardımcı olur.
Nereden alınır?
Her 'ServiceRequestId' için etkinlik dizisine iş kuralları uygulanarak veri dönüşümü sırasında hesaplanır.
Örnekler
truefalse
|
|||
Hizmet Talebi Yönetimi Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Harici tedarikçi sürece dahil oldu
|
Bir ticket'ın çözüm için harici bir tedarikçiye veya üçüncü tarafa devredildiği zamanı gösterir. Ticket durumunun 'Pending Vendor' veya 'Awaiting Third Party' gibi belirli bir duruma değişmesi üzerinden çıkarılır. | ||
|
Neden önemli?
Tedarikçinin sürece dahil olması önemli gecikmelere yol açabilir. Bu faaliyeti izlemek, tedarikçi performansını ve bunun genel Service Request çevrim süresine etkisini ölçmek için gereklidir.
Nereden alınır?
Ticket 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 bulun.
Yakalayın
Ticket durum alanının üçüncü bir tarafı beklemeyi ifade eden bir değere değiştiği zamanı tespit edin.
Olay türü
inferred
|
|||
|
Service Request çözüldü
|
Bu önemli kilometre taşı, temsilcinin bir çözüm sunduğu ve çalışmayı tamamlanmış kabul ettiği noktayı gösterir. Ticket durumunun 'Resolved' durumuna değişmesi üzerinden çıkarılır. | ||
|
Neden önemli?
Bu faaliyet, aktif çalışma aşamasının sona erdiğini gösterir. Bu noktaya kadar geçen süre, temsilci ve süreç verimliliğinin önemli bir ölçüsüdür ve SLA hesaplamalarının temelini oluşturur.
Nereden alınır?
Ticket durum değişikliği geçmişinden çıkarılır. Durumun ilk kez 'Resolved' olarak ayarlandığı zaman damgasına karşılık gelir.
Yakalayın
Ticket durumunun ilk kez 'Resolved' durumuna değiştiği zaman damgasını kaydedin.
Olay türü
inferred
|
|||
|
Service Request kapatıldı
|
Bu, Service Request yaşam döngüsünün sona erdiğini gösteren son faaliyettir. Ticket yeniden açılmadan 'Resolved' 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 sahibi için onay penceresini temsil eder.
Nereden alınır?
Ticket durum değişikliği geçmişinden çıkarılır. Durumun 'Closed' durumuna değiştiği zaman damgasına karşılık gelir.
Yakalayın
Ticket durumunun 'Closed' durumuna değiştiği zaman damgasını kaydedin.
Olay türü
inferred
|
|||
|
Service Request oluşturuldu
|
Bu faaliyet, yeni bir talebin Freshservice sistemine resmî olarak kaydedilmesiyle Service Request yaşam döngüsünün başladığı noktayı gösterir. Yeni bir ticket kaydı servis kataloğu, e-posta veya başka bir kanal üzerinden oluşturulduğunda bu olay açıkça kaydedilir ve benzersiz bir Service Request ID oluşturulur. | ||
|
Neden önemli?
Bu, sürecin birincil başlangıç olayıdır. Bu faaliyet ile diğer faaliyetler arasındaki süreyi analiz etmek, toplam çevrim sürelerini ölçmek ve ilk işlem gecikmelerini belirlemek için temel oluşturur.
Nereden alınır?
Bu olay Freshservice sistemine açıkça kaydedilir. Genellikle ticket oluşturma zaman damgasına karşılık gelecek şekilde ticket'ın faaliyet günlüğünde veya denetim izinde bulunabilir.
Yakalayın
Freshservice ticket verilerindeki ticket oluşturma zaman damgasını kullanın.
Olay türü
explicit
|
|||
|
SLA hedefi aşıldı
|
Bir Service Request'i çözme süresi, tanımlanan Service Level Agreement (SLA) hedefini aştığında gerçekleşen hesaplanmış bir olaydır. Bu, doğrudan bir sistem olayı değildir. Çözüm süresi SLA son tarihine göre karşılaştırılarak türetilir. | ||
|
Neden önemli?
Bu olay, hizmet performansını taahhütlere göre doğrudan ölçer ve yönetim için önemli bir KPI'dır. Hangi talep türlerinin veya önceliklerin hedefi karşılayamama riskinin daha yüksek olduğunu belirlemeye yardımcı olur.
Nereden alınır?
'Resolved' zaman damgası ile 'SLA Due By' zaman damgası karşılaştırılarak hesaplanır. Çözüm zamanı daha sonraysa bu olay tetiklenir.
Yakalayın
Çözüm zaman damgasını SLA son tarih zaman damgasıyla karşılaştırın. resolved_at > sla_due_by ise bu olayı oluşturun.
Olay türü
calculated
|
|||
|
Talep temsilciye atandı
|
Bir Service Request'in işlenmek üzere belirli bir temsilciye atandığı noktayı gösterir. Bu önemli kilometre taşı, ticket için 'Assigned Agent' veya 'Owner' alanlarındaki değişiklikler izlenerek çıkarılır. | ||
|
Neden önemli?
Bu faaliyet, temsilci iş yükünü analiz etmek ve atama sürecindeki darboğazları belirlemek için önemlidir. Oluşturma ile atama arasındaki süre, önemli bir performans göstergesidir.
Nereden alınır?
Ticket'ın faaliyet günlüğü veya alan denetim izi, 'Agent' ya da 'Assignee' alanındaki değişiklikler izlenerek incelenir.
Yakalayın
'Assigned Agent' alanının doldurulduğu veya değerinin değiştiği zaman damgasını kaydedin.
Olay türü
inferred
|
|||
|
Çözüm talep sahibi tarafından onaylandı
|
Talep sahibinin sunulan çözümün yeterli olduğunu açıkça onaylamasını ifade eder. Ticket kapatılmadan önce verilen olumlu bir anket yanıtı veya belirli bir yorum üzerinden çıkarılabilir. | ||
|
Neden önemli?
Onay, çözüm kalitesi hakkında doğrudan geri bildirim sağlar. Düşük onay oranı, talepler yeniden açılmasa bile çözümlerin kullanıcı ihtiyaçlarını tam olarak karşılamadığını gösterebilir.
Nereden alınır?
Bu bilgiyi doğrudan yakalamak zordur ve özel yapılandırma gerektirebilir. Ticket ile ilişkilendirilmiş müşteri memnuniyeti anketi yanıtından veya uygulanan belirli bir etiketten çıkarılabilir.
Yakalayın
Çözüm sonrasında uygulanan etiketler veya memnuniyet anketleri gibi ilişkili verilerin analiz edilmesi gerekir.
Olay türü
inferred
|
|||
|
Dahili inceleme yapıldı
|
Önerilen bir çözümün veya talep karşılamanın ilerlemeden önce dahili inceleme ya da onay gerektirdiğini gösterir. Ticket durumunun 'Pending Approval' veya 'Internal Review' gibi bir duruma değişmesi üzerinden çıkarılır. | ||
|
Neden önemli?
Dahili incelemeler, özellikle karmaşık veya etkisi yüksek Service Request süreçlerinde darboğaz oluşturabilir. Bu sürenin ölçülmesi, onay Workflow süreçlerini daha akıcı hale getirmeye yardımcı olur.
Nereden alınır?
Ticket durum değişikliği geçmişinden çıkarılır. Workflow içinde 'Pending Internal Approval' gibi belirli bir durumun kullanılması gerekir.
Yakalayın
Ticket durum alanının dahili inceleme veya onayı ifade eden bir değere değiştiği zamanı tespit edin.
Olay türü
inferred
|
|||
|
Not eklendi
|
Bir temsilci veya talep sahibi tarafından Service Request'e eklenen herkese açık ya da özel notları ifade eder. Bu, ticket'ın konuşma veya faaliyet günlüğünde kaydedilen açık bir olaydır. | ||
|
Neden önemli?
Notların sıklığını ve zamanlamasını analiz etmek, iletişim kalıplarını, iş birliği verimliliğini ve süreçteki belirsizlik noktalarını ortaya çıkarabilir.
Nereden alınır?
Freshservice içindeki ticket konuşma geçmişine açıkça kaydedilir. Her notta bir zaman damgası ve yazar bilgisi bulunur.
Yakalayın
Ticket'ın konuşma veya yorum günlüğündeki her kaydı çıkarın.
Olay türü
explicit
|
|||
|
Service Request yeniden açıldı
|
Talep sahibi, bir sorun 'Resolved' olarak işaretlendikten sonra devam ettiğini bildirdiğinde gerçekleşir ve ticket yeniden açık duruma döner. Ticket durumunun 'Resolved' durumundan 'Open' veya 'In Progress' durumuna değişmesi üzerinden çıkarılır. | ||
|
Neden önemli?
Yeniden açılan talepler, ilk temasta çözüm oranının düşük olduğuna ve müşteri memnuniyetsizliğine güçlü biçimde işaret eder. Bu yeniden iş döngüsünü izlemek, çözüm kalitesini iyileştirmek için önemlidir.
Nereden alınır?
Faaliyet günlüğündeki ticket durum değişikliği geçmişinden çıkarılır. Bu, 'Resolved' durumundan 'Open' durumuna doğrudan geçiştir.
Yakalayın
Durumun çözülmüş bir değerden açık duruma değiştiğini tespit edin.
Olay türü
inferred
|
|||
|
Talep ön değerlendirmeden geçirildi
|
Yeni oluşturulan bir Service Request için yapılan ilk değerlendirmeyi ve kategorilendirmeyi ifade eder. Bu faaliyet genellikle önceliğin ilk kez belirlenmesi veya talebin bir gruba atanması üzerinden çıkarılır. Bu, talebin incelendiğini ve kuyruğa alındığını gösterir. | ||
|
Neden önemli?
Ön değerlendirmeyi izlemek, ilk yanıt ekibinin verimliliğini ölçmeye yardımcı olur. Bu aşamadaki gecikmeler, genel çözüm sürelerini ve SLA uyumluluğunu önemli ölçüde etkileyebilir.
Nereden alınır?
Faaliyet günlüğünden çıkarılır. Oluşturma sonrasında gerçekleşen ilk 'Priority Set' veya 'Group Assigned' olayının zaman damgası belirlenerek tespit edilebilir.
Yakalayın
Öncelik alanındaki değişiklik ile atama grubu alanındaki değişiklikten hangisi daha erkense onun zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep önceliklendirildi
|
Low, Medium veya High gibi bir öncelik düzeyi Service Request için atandığında gerçekleşir. Ticket geçmişindeki 'Priority' alanı değişikliği tespit edilerek çıkarılır. | ||
|
Neden önemli?
Önceliklendirme, kaynakların dağıtılması ve SLA hedeflerinin karşılanması için önemlidir. Bu faaliyetin analizi, taleplerin doğru ve zamanında değerlendirilip değerlendirilmediğini doğrulamaya yardımcı olur.
Nereden alınır?
Freshservice içindeki ticket alan değişikliği geçmişinden çıkarılır. 'Priority' alanındaki güncellemeleri bulun ve değişikliğin zaman damgasını kaydedin.
Yakalayın
'Priority' alanında null değerinden veya önceki değerinden bir değişiklik tespit edin ve zaman damgasını kaydedin.
Olay türü
inferred
|
|||
|
Talep sahibi bilgi sağladı
|
Talep sahibi gerekli bilgileri sağladığında gerçekleşir ve temsilcinin çalışmaya devam etmesini sağlar. Genellikle ticket durumunun 'Pending' durumundan otomatik olarak 'Open' durumuna dönmesi üzerinden çıkarılır. | ||
|
Neden önemli?
Bu faaliyet, bilgi taleplerinin sonuçlanmasını gösterir. Bilginin istenmesi ile sağlanması arasındaki süre, analiz edilmesi ve iyileştirilmesi gereken önemli bir bekleme süresidir.
Nereden alınır?
Ticket durumunun 'Pending' durumundan 'Open' veya 'In Progress' durumuna değişmesi üzerinden çıkarılır. Bu değişiklik çoğu zaman talep sahibinin yanıtıyla tetiklenir.
Yakalayın
Ticket durumunun beklemedeki bir değerden açık duruma değiştiği zamanı tespit edin.
Olay türü
inferred
|
|||
|
Talep sahibinden bilgi istendi
|
Atanan temsilcinin talep sahibinden daha fazla bilgi istediği ve sürecin ilerlemesini duraklattığı noktayı ifade eder. Ticket durumunun 'Pending' veya 'Awaiting Customer' durumuna değişmesi üzerinden çıkarılır. | ||
|
Neden önemli?
Bu faaliyet, gecikme ve yeniden işleme neden olan yaygın bir durumu ortaya çıkarır. Sıklığını analiz etmek, talep şablonlarını ve ilk veri toplama adımını iyileştirme fırsatlarını belirlemeye yardımcı olur.
Nereden alınır?
Ticket durum değişikliği geçmişinden çıkarılır. 'Pending Customer Response' veya 'Awaiting Information' gibi bir duruma geçişi bulun.
Yakalayın
Ticket durum alanının kullanıcı girdisi beklemeyi ifade eden bir değere değiştiği zamanı tespit edin.
Olay türü
inferred
|
|||
|
Talep yeniden atandı
|
İlk atamadan sonra atanan temsilcide veya grupta gerçekleşen değişiklikleri kaydeder. 'Assigned Agent' veya 'Assigned Group' alanlarında sonraki güncellemeler tespit edilerek çıkarılır. | ||
|
Neden önemli?
Sık yeniden atamalar, ilk ön değerlendirmede, temsilci yetkinliklerinin eşleştirilmesinde veya iş yükü dengesinde sorunlar olabileceğini gösterir. Bu faaliyet, Agent Reassignment Count KPI'ı ve yeniden iş analizi için önemlidir.
Nereden alınır?
Ticket'ın alan değişikliği geçmişinden çıkarılır. İlk değer belirlendikten sonra 'Assigned Agent' veya 'Assigned Group' alanı her güncellendiğinde bu olay kaydedilir.
Yakalayın
İlk atamadan sonra 'Assigned Agent' veya 'Assigned Group' alanında gerçekleşen tüm 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 etmeye yönelik ilk adımı atın. Hizmet sunumunuzu dönüştürmenize destek olmak için buradayız.
Freshservice'te hizmet talebi verimliliğini bugün artırın
Yavaş tamamlamayı ve kullanıcı memnuniyetsizliğini sona erdirin, %70 otomasyona ulaşın.
Kredi kartı gerekmez. Kurulum birkaç dakika sürer.