Templat data pengelolaan insiden
Templat data pengelolaan insiden
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama untuk dilacak dalam pemetaan proses
- Panduan praktis untuk mengekstrak data
Atribut pengelolaan insiden
| Nama | Deskripsi | ||
|---|---|---|---|
|
ID Insiden
TicketId
|
Pengenal unik yang dibuat sistem untuk setiap tiket insiden. | ||
|
Deskripsi
ID Insiden adalah kunci utama yang membedakan setiap kasus insiden di Zendesk Support. Dalam process mining, ID ini berfungsi sebagai CaseId yang menghubungkan semua aktivitas, perubahan status, dan komunikasi terkait, sejak insiden dibuat hingga ditutup. ID ini penting untuk menyusun kembali perjalanan setiap insiden dari awal hingga akhir. ID memungkinkan data peristiwa digabungkan untuk melacak metrik seperti total waktu penyelesaian, jumlah serah terima, dan kepatuhan terhadap perjanjian tingkat layanan untuk setiap kasus. Dengan mengelompokkan peristiwa berdasarkan ID ini, analis dapat memvisualisasikan alur proses, menemukan jalur yang umum, dan mendeteksi penyimpangan dari prosedur standar.
Mengapa ini penting
Pengenal penting ini menghubungkan semua peristiwa dengan satu insiden, sehingga seluruh siklusnya dapat ditelusuri dan kinerja proses dianalisis secara akurat.
Sumber data
Zendesk Tickets API (/api/v2/tickets/{id}), kolom id.
Contoh
19428230113521941055
|
|||
|
Stempel waktu peristiwa
EventTimestamp
|
Tanggal dan waktu tepat saat aktivitas terjadi. | ||
|
Deskripsi
Stempel waktu ini mencatat saat suatu peristiwa terjadi dalam siklus insiden, misalnya saat komentar ditambahkan atau status diubah. Informasi ini menentukan urutan waktu semua aktivitas dalam satu kasus. Atribut ini menjadi dasar analisis process mining berbasis waktu. Data ini digunakan untuk menghitung waktu siklus antaraktivitas, menemukan waktu tunggu, mengukur durasi kasus secara keseluruhan, dan menganalisis kinerja proses dalam berbagai periode. Stempel waktu yang akurat diperlukan untuk membuat peta proses animasi yang menunjukkan alur kasus dari waktu ke waktu, serta menyusun dashboard kinerja untuk memantau KPI seperti rata-rata waktu penyelesaian.
Mengapa ini penting
Stempel waktu memberikan konteks kronologis untuk semua aktivitas, sehingga durasi dapat dihitung, hambatan dapat ditemukan, dan kinerja proses dapat dianalisis dari waktu ke waktu.
Sumber data
Zendesk Ticket Audits API (/api/v2/tickets/{ticket_id}/audits), kolom created_at untuk setiap peristiwa audit.
Contoh
2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
|
|||
|
Aktivitas
ActivityName
|
Nama aktivitas bisnis atau peristiwa yang terjadi pada titik tertentu dalam siklus insiden. | ||
|
Deskripsi
Atribut ini menjelaskan langkah atau tindakan tertentu dalam proses manajemen insiden, seperti 'Insiden dibuat', 'Tiket ditugaskan ke agen', atau 'Insiden diselesaikan'. Aktivitas ini diambil dari log peristiwa atau data jejak audit Zendesk, tempat perubahan sistem dicatat. Dalam process mining, urutan aktivitas membentuk peta proses yang menjadi dasar seluruh analisis. Dengan menganalisis alur aktivitas, organisasi dapat mengetahui jalur yang benar-benar ditempuh insiden, menemukan hambatan antarlangkah, mengukur siklus pengerjaan ulang, misalnya tiket yang dibuka kembali setelah diselesaikan, dan memeriksa kesesuaian dengan proses standar yang telah ditetapkan.
Mengapa ini penting
Urutan aktivitas membentuk alur proses, inti analisis process mining untuk menemukan inefisiensi, penyimpangan, dan peluang perbaikan.
Sumber data
Diambil dari peristiwa di Zendesk Ticket Audits API. Misalnya, peristiwa Change pada kolom status dapat dipetakan menjadi 'Status berubah'.
Contoh
Insiden dibuatTiket ditugaskan ke agenStatus berubah menjadi menungguInsiden diselesaikanInsiden ditutup
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Stempel waktu yang menunjukkan kapan data untuk proses ini terakhir diperbarui. | ||
|
Deskripsi
Atribut ini mencatat tanggal dan waktu ekstraksi atau pembaruan data terbaru dari sistem sumber. Biasanya, satu nilai berlaku untuk seluruh dataset dari satu siklus pembaruan. Informasi ini penting untuk tata kelola data dan bagi pengguna analisis process mining. Informasi ini menunjukkan seberapa baru data yang digunakan, sehingga analis dapat mengetahui apakah mereka melihat informasi terkini. Hal ini sangat penting untuk memantau kinerja operasional dan mengambil keputusan tepat waktu berdasarkan hasil analisis.
Mengapa ini penting
Memberikan konteks penting tentang kebaruan data, sehingga pengguna mengetahui seberapa terkini analisis dan kapan data terakhir diambil.
Sumber data
Stempel waktu yang dibuat oleh proses ETL/alur data setelah pembaruan data selesai.
Contoh
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
Sistem sumber
SourceSystem
|
Sistem tempat data insiden diambil. | ||
|
Deskripsi
Atribut ini menunjukkan asal data proses. Untuk tampilan ini, nilainya bersifat tetap, misalnya 'Zendesk Support', yang menunjukkan bahwa semua peristiwa dan atribut berasal dari sistem tersebut. Jika data dari beberapa sistem digabungkan, kolom ini penting untuk membedakan sumber data. Kolom ini membantu menjaga integritas data dan memungkinkan analisis berdasarkan sumber, misalnya membandingkan proses manajemen insiden di Zendesk dengan alat ITSM lainnya.
Mengapa ini penting
Menunjukkan asal data, hal yang penting untuk tata kelola data dan analisis yang menggabungkan data dari beberapa sistem sumber.
Sumber data
Nilai tetap yang ditetapkan selama transformasi data untuk menunjukkan asal data.
Contoh
Zendesk SupportZendesk
|
|||
|
Agen yang ditugaskan
Assignee
|
Agen dukungan yang saat ini ditugaskan untuk menangani insiden. | ||
|
Deskripsi
Atribut ini menunjukkan agen yang bertanggung jawab atas insiden pada waktu tertentu. Perubahan agen yang ditugaskan merupakan peristiwa penting karena menandai perpindahan pekerjaan dari satu orang ke orang lain. Analisis agen yang ditugaskan membantu Anda memahami pembagian beban kerja, kinerja individu, dan pola kolaborasi. Melacak perubahan pada field ini penting untuk menghitung KPI 'Rata-rata perpindahan tugas per insiden' dan menemukan insiden yang sering berpindah tangan. Hal ini dapat menunjukkan kesenjangan pengetahuan atau alur penugasan yang kurang efisien.
Mengapa ini penting
Menunjukkan agen yang bertanggung jawab, sehingga Anda dapat menganalisis beban kerja dan melacak perpindahan tugas untuk menemukan inefisiensi proses.
Sumber data
Zendesk Tickets API, field assignee_id. Perubahan dicatat di Ticket Audits API.
Contoh
John SmithJane DoeOtomatisasi meja layanan
|
|||
|
Grup yang ditugaskan
AssignedGroup
|
Tim atau grup dukungan yang saat ini ditugaskan untuk menangani insiden. | ||
|
Deskripsi
Atribut ini menunjukkan tim yang bertanggung jawab atas insiden. Insiden sering berpindah antarlevel dukungan atau grup khusus, misalnya dari 'Dukungan L1' ke 'Tim Jaringan'. Atribut ini penting untuk menganalisis perpindahan tugas antargrup dan menemukan hambatan. Dengan memantau alur insiden antargrup, analis dapat mengukur ketergantungan antartim, menghitung waktu antrean tiap tim, dan menyempurnakan aturan penugasan. Atribut ini mendukung langsung dashboard 'Analisis perpindahan tugas dan pengerjaan ulang'.
Mengapa ini penting
Melacak tim yang bertanggung jawab. Informasi ini penting untuk menganalisis perpindahan tugas antartim, menemukan hambatan pada tim tertentu, dan mengukur waktu antrean.
Sumber data
Zendesk Tickets API, field group_id. Perubahan dicatat di Ticket Audits API.
Contoh
Dukungan L1Tim Jaringan L2Infrastruktur L3Penagihan
|
|||
|
Prioritas
TicketPriority
|
Tingkat prioritas insiden, seperti 'Rendah', 'Normal', 'Tinggi', atau 'Mendesak'. | ||
|
Deskripsi
Prioritas insiden menentukan seberapa cepat tim perlu merespons dan menyelesaikannya. Prioritas juga menjadi faktor utama dalam menentukan urutan pekerjaan dan alokasi sumber daya tim dukungan. Dalam analisis proses, prioritas digunakan untuk mengelompokkan insiden dan membandingkan alur serta kinerjanya. Misalnya, analis dapat memeriksa apakah insiden 'Mendesak' benar-benar selesai lebih cepat daripada insiden berprioritas 'Rendah'. Prioritas juga digunakan untuk memantau kepatuhan SLA, karena target SLA sering ditetapkan berdasarkan tingkat prioritas. KPI 'Tingkat perubahan prioritas' mengandalkan pelacakan perubahan pada field ini.
Mengapa ini penting
Atribut ini penting untuk mengelompokkan analisis, menilai efektivitas penentuan prioritas, dan memantau kepatuhan SLA pada tiap tingkat urgensi.
Sumber data
Zendesk Tickets API, field priority. Perubahan dicatat di Ticket Audits API.
Contoh
rendahnormaltinggimendesak
|
|||
|
Saluran pelaporan
Channel
|
Saluran yang digunakan untuk pertama kali melaporkan insiden, seperti 'Email', 'Web', atau 'API'. | ||
|
Deskripsi
Atribut ini mencatat cara pengguna akhir atau sistem membuat tiket insiden. Informasi saluran membantu Anda menganalisis sumber insiden dan menyesuaikan proses dukungan. Analisis insiden berdasarkan saluran dapat menunjukkan pola yang berbeda. Misalnya, insiden yang dilaporkan melalui telepon mungkin lebih cepat diselesaikan daripada yang dilaporkan melalui email. Informasi ini mendukung dashboard 'Volume penanganan insiden' serta membantu perencanaan sumber daya dan optimalisasi saluran.
Mengapa ini penting
Membantu menganalisis volume insiden dan kinerja proses berdasarkan sumbernya, sehingga Anda dapat memperbaiki proses dan mengalokasikan sumber daya sesuai saluran.
Sumber data
Zendesk Tickets API, field via.channel.
Contoh
webemailapitelepon
|
|||
|
Status SLA
SlaStatus
|
Status Service Level Agreement (SLA) untuk insiden saat ini. | ||
|
Deskripsi
Atribut ini menunjukkan apakah insiden masih sesuai target SLA, sudah melampaui target, atau penghitung waktu SLA sedang dijeda. Zendesk melacak metrik SLA secara otomatis berdasarkan kebijakan yang dikonfigurasi. Atribut ini penting untuk dashboard 'Pemantauan kepatuhan SLA'. Atribut ini mengukur secara langsung kinerja terhadap komitmen layanan. Dengan menganalisis kapan dan mengapa SLA terlampaui, organisasi dapat menemukan kelemahan proses dan meningkatkan keandalan layanan. Atribut ini juga mendukung KPI 'Tingkat pemenuhan SLA insiden'.
Mengapa ini penting
Mengukur kinerja terhadap komitmen layanan secara langsung, sehingga Anda dapat menganalisis pelanggaran SLA dan memantaunya secara proaktif untuk meningkatkan kepatuhan.
Sumber data
Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), diturunkan dari field seperti sla_policy, breached_at, dan lainnya.
Contoh
AktifDijedaTerlewatiTerpenuhi
|
|||
|
Status tiket
TicketStatus
|
Status tiket insiden saat peristiwa terjadi, misalnya 'Terbuka', 'Menunggu', atau 'Selesai'. | ||
|
Deskripsi
Atribut ini menunjukkan keadaan tiket insiden pada berbagai tahap siklusnya. Status standar Zendesk mencakup new, open, pending, on-hold, solved, dan closed. Melacak perubahan kolom ini merupakan cara utama untuk menghasilkan aktivitas bagi process mining. Analisis status tiket penting untuk memahami proses. Analisis ini membantu mengetahui berapa lama insiden berada dalam status tertentu, seperti 'Pending', yang sering menunjukkan bahwa tim sedang menunggu tanggapan pelanggan. Status tiket juga penting untuk menentukan kapan kasus selesai dan menghitung waktu penyelesaian.
Mengapa ini penting
Melacak perubahan status penting untuk memahami perkembangan proses, mengetahui waktu tunggu, serta menentukan awal dan akhir siklus penanganan insiden.
Sumber data
Zendesk Tickets API, field status. Perubahan dicatat di Ticket Audits API.
Contoh
baruterbukamenungguterselesaikanditutup
|
|||
|
Waktu akhir peristiwa
EventEndTime
|
Waktu yang menunjukkan kapan suatu aktivitas selesai. | ||
|
Deskripsi
Waktu akhir peristiwa menandai selesainya suatu aktivitas. Dalam data log peristiwa, waktu akhir suatu aktivitas sering diperkirakan dari waktu mulai aktivitas berikutnya dalam urutan kasus yang sama. Untuk aktivitas terakhir dalam kasus, waktu akhirnya bisa sama dengan waktu mulainya. Atribut ini penting untuk menghitung durasi setiap aktivitas (ProcessingTime) dan waktu tunggu antaraktivitas. Informasi ini menjadi dasar analisis hambatan. Analis dapat melihat berapa lama suatu langkah berlangsung dan berapa lama kasus tidak bergerak sebelum langkah itu dimulai.
Mengapa ini penting
Memungkinkan Anda menghitung durasi aktivitas dan waktu tunggu. Perhitungan ini menjadi dasar analisis hambatan secara terperinci dan membantu menemukan keterlambatan proses.
Sumber data
Dihitung dari waktu mulai peristiwa berikutnya dalam kasus yang sama. Waktu akhir peristiwa terakhir dapat sama dengan waktu mulainya atau waktu kasus ditutup.
Contoh
2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
|
|||
|
Apakah otomatis
IsAutomated
|
Penanda boolean yang menunjukkan apakah aktivitas dilakukan oleh sistem otomatis atau agen manusia. | ||
|
Deskripsi
Atribut turunan ini membedakan peristiwa yang dilakukan pengguna dengan peristiwa yang dijalankan oleh otomatisasi sistem, pemicu, atau integrasi API. Biasanya, atribut ini ditentukan dengan memeriksa apakah penulis peristiwa merupakan pengguna sistem yang dikenal. Memahami tingkat otomatisasi penting untuk analisis proses saat ini. Informasi ini membantu Anda menilai efektivitas aturan otomatisasi, menemukan tugas manual yang dapat diotomatisasi, dan mengukur dampak otomatisasi terhadap efisiensi serta waktu penyelesaian. Anda juga dapat membandingkan alur proses untuk aktivitas otomatis dan manual.
Mengapa ini penting
Membedakan tindakan manusia dan sistem. Informasi ini penting untuk menganalisis dampak otomatisasi terhadap efisiensi proses dan menemukan peluang otomatisasi baru.
Sumber data
Ditentukan dengan memeriksa apakah penulis peristiwa (author_id di Ticket Audits API) merupakan pengguna sistem atau otomatisasi yang dikenal.
Contoh
truefalse
|
|||
|
Apakah selesai pada kontak pertama
IsFirstContactResolution
|
Penanda boolean bernilai benar jika insiden diselesaikan oleh agen atau grup pertama yang ditugaskan, tanpa perpindahan tugas. | ||
|
Deskripsi
Penyelesaian pada kontak pertama (FCR) merupakan metrik penting untuk mengukur efisiensi pusat dukungan dan kepuasan pelanggan. Atribut hasil perhitungan ini menandai insiden yang selesai tanpa dialihkan ke agen atau tim lain. Logikanya biasanya memeriksa apakah tiket mencapai status 'Terselesaikan' saat masih ditangani oleh agen dan grup awal. Dalam process mining, atribut ini memungkinkan Anda menghitung tingkat FCR secara langsung dan membandingkan jalur proses insiden yang selesai pada kontak pertama dengan insiden yang perlu dieskalasikan. Hasilnya membantu menemukan peluang agar tim dukungan lini depan dapat menyelesaikan lebih banyak insiden.
Mengapa ini penting
Mengukur langsung efisiensi penanganan awal dan membantu menemukan peluang untuk menyelesaikan insiden lebih awal dalam proses.
Sumber data
Penanda boolean hasil perhitungan. Bernilai benar jika status tiket 'solved' atau 'closed' dan hanya ada satu agen atau grup yang ditugaskan selama siklus penanganan insiden.
Contoh
truefalse
|
|||
|
Durasi kasus
CaseDuration
|
Total waktu sejak insiden dibuat hingga akhirnya ditutup. | ||
|
Deskripsi
Metrik hasil perhitungan ini menunjukkan waktu siklus dari awal hingga akhir untuk satu insiden. Nilainya dihitung dari selisih waktu antara peristiwa pertama (misalnya, 'Insiden dibuat') dan peristiwa terakhir (misalnya, 'Insiden ditutup'). Durasi kasus merupakan KPI utama untuk mengukur efisiensi proses secara keseluruhan. Metrik ini banyak digunakan di dashboard untuk menampilkan rata-rata waktu siklus, menemukan kasus yang berlangsung lama, dan menganalisis tren dari waktu ke waktu. Metrik ini memberi gambaran umum tentang seberapa cepat proses menangani dan menyelesaikan insiden.
Mengapa ini penting
KPI ini penting untuk mengukur kecepatan proses secara keseluruhan dan menemukan faktor yang memperpanjang waktu penyelesaian.
Sumber data
Dihitung dengan mencari selisih waktu antara peristiwa terakhir dan pertama untuk setiap Incident ID.
Contoh
25920060480086400
|
|||
|
Jenis tiket
TicketType
|
Klasifikasi tiket, seperti 'Insiden', 'Masalah', 'Pertanyaan', atau 'Tugas'. | ||
|
Deskripsi
Field ini mengelompokkan tiket berdasarkan jenis permintaan. Proses manajemen insiden berfokus pada tiket berjenis 'Insiden', yaitu gangguan tak terencana atau penurunan kualitas layanan TI. Dalam analisis, atribut ini terutama digunakan sebagai filter agar tampilan proses hanya mencakup insiden. Atribut ini juga dapat digunakan untuk analisis ITSM yang lebih luas, misalnya membandingkan penanganan insiden, masalah, dan permintaan layanan.
Mengapa ini penting
Memungkinkan Anda memfilter data agar hanya berfokus pada insiden, sehingga analisis proses sesuai dengan siklus penanganan insiden.
Sumber data
Zendesk Tickets API, field type.
Contoh
insidenmasalahpertanyaantugas
|
|||
|
Jumlah perpindahan tugas
HandoffCount
|
Jumlah total insiden yang dialihkan ke agen atau grup lain. | ||
|
Deskripsi
Metrik hasil perhitungan ini menunjukkan berapa kali tanggung jawab atas suatu insiden berpindah. Setiap perubahan pada field Assignee atau AssignedGroup menambah hitungan untuk kasus tersebut. Perpindahan tugas sering menyebabkan inefisiensi dan keterlambatan dalam penanganan insiden. Jumlah perpindahan yang tinggi dapat menunjukkan aturan penugasan yang kurang jelas, kesenjangan pengetahuan dalam tim dukungan, atau proses yang terlalu rumit. Metrik ini menjadi dasar KPI 'Rata-rata perpindahan tugas per insiden' dan penting untuk dashboard 'Analisis perpindahan tugas dan pengerjaan ulang'.
Mengapa ini penting
Mengukur hambatan dalam proses akibat perpindahan tugas, sehingga Anda dapat menemukan masalah penugasan dan kesenjangan pengetahuan yang memperpanjang waktu penyelesaian.
Sumber data
Dihitung dengan menghitung berapa kali field AssignedGroup atau Assignee berubah untuk suatu insiden.
Contoh
0135
|
|||
|
Kategori akar penyebab
RootCauseCategory
|
Kategori umum yang menjelaskan akar penyebab insiden. | ||
|
Deskripsi
Atribut ini digunakan untuk mengelompokkan penyebab utama insiden. Biasanya, data ini dicatat menjelang akhir siklus penanganan insiden, misalnya saat evaluasi pascainsiden atau proses manajemen masalah, lalu disimpan di field khusus. Data ini penting untuk dashboard 'Akurasi identifikasi akar penyebab' dan KPI 'Cakupan analisis akar penyebab'. Analisis insiden berdasarkan akar penyebab membantu menemukan masalah berulang dan menentukan perbaikan permanen untuk mengurangi jumlah insiden di masa mendatang. Dengan begitu, fokus beralih dari penanganan reaktif ke pencegahan masalah.
Mengapa ini penting
Mendukung manajemen masalah proaktif dengan mengelompokkan penyebab insiden, sehingga Anda dapat menemukan tren dan mencegah kejadian serupa.
Sumber data
Biasanya berupa field tiket khusus. Periksa konfigurasi Ticket Fields di Zendesk Admin Center.
Contoh
Bug perangkat lunakKerusakan perangkat kerasKesalahan penggunaGangguan jaringan
|
|||
|
Organisasi pelanggan
Organization
|
Organisasi atau perusahaan tempat pemohon insiden bekerja. | ||
|
Deskripsi
Atribut ini menghubungkan insiden dengan organisasi pelanggan. Atribut ini penting untuk dukungan B2B, karena tingkat layanan dan proses dukungan dapat berbeda untuk setiap pelanggan. Analisis insiden berdasarkan organisasi membantu tim dukungan memantau kondisi pelanggan, menemukan masalah berulang yang berdampak pada klien tertentu, dan memastikan kewajiban kontrak terpenuhi. Atribut ini juga berguna untuk memfilter dashboard dan laporan agar kinerja dapat dilihat dari sudut pandang pelanggan.
Mengapa ini penting
Memungkinkan analisis untuk tiap pelanggan, membantu Anda memantau tingkat layanan, menemukan tren pada akun utama, dan mengelola hubungan pelanggan dengan lebih baik.
Sumber data
Zendesk Tickets API, field organization_id.
Contoh
Global Tech Inc.Innovate SolutionsData Corp
|
|||
|
Pelapor
Submitter
|
Pengguna akhir atau sistem yang pertama kali melaporkan insiden. | ||
|
Deskripsi
Atribut ini menunjukkan orang atau entitas yang membuat tiket. Pelapor berbeda dari pemohon, karena agen dapat membuat tiket atas nama orang lain. Dalam analisis, data pelapor membantu Anda memahami siapa yang melaporkan masalah. Jika dipadukan dengan data organisasi, informasi ini dapat menunjukkan pelanggan atau kelompok pengguna yang mengalami banyak insiden. Temuan tersebut dapat menjadi dasar untuk dukungan proaktif atau pelatihan.
Mengapa ini penting
Menunjukkan sumber laporan insiden. Anda dapat menganalisisnya untuk menemukan pola yang terkait dengan pengguna, departemen, atau sistem otomatis tertentu.
Sumber data
Zendesk Tickets API, field submitter_id.
Contoh
alice.jones@example.combob.williams@example.comPemantau sistem
|
|||
|
Penilaian kepuasan
SatisfactionRating
|
Penilaian kepuasan yang diberikan pengguna akhir setelah insiden diselesaikan. | ||
|
Deskripsi
Atribut ini mencatat masukan pelanggan tentang pengalaman mereka saat menerima dukungan. Biasanya, masukan dikumpulkan melalui survei setelah tiket ditandai selesai. Di Zendesk, penilaian yang umum digunakan adalah 'Baik' atau 'Buruk'. Penilaian kepuasan bukan ukuran langsung efisiensi proses, tetapi menjadi metrik hasil yang penting. Dalam process mining, penilaian ini dapat dibandingkan dengan variasi proses untuk mengetahui jalur penyelesaian yang menghasilkan kepuasan pelanggan lebih tinggi. Misalnya, apakah insiden yang mengalami lebih banyak perpindahan tugas mendapat penilaian lebih rendah?
Mengapa ini penting
Memberikan metrik hasil penting yang dapat dibandingkan dengan karakteristik proses untuk memahami dampak kinerja proses terhadap kepuasan pengguna.
Sumber data
Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), field satisfaction_rating.score.
Contoh
baikburukditawarkantidak ditawarkan
|
|||
|
Tag
Tags
|
Daftar tag yang diterapkan pada insiden untuk pengelompokan dan konteks tambahan. | ||
|
Deskripsi
Tag adalah label fleksibel yang dapat ditambahkan ke tiket untuk memberi konteks atau membantu pengelompokan dan penentuan alur. Agen dapat menambahkannya secara manual, atau tag dapat ditambahkan otomatis melalui pemicu dan otomatisasi. Tag menyediakan banyak informasi untuk analisis process mining. Anda dapat menggunakannya untuk membuat kelompok analisis yang lebih terperinci, misalnya memfilter insiden terkait peluncuran produk tertentu ('launch_q4') atau gangguan yang diketahui ('outage_20231027'). Fleksibilitas ini memungkinkan analisis mendalam yang melampaui field tiket standar.
Mengapa ini penting
Memberikan cara fleksibel untuk mengelompokkan dan memfilter insiden, sehingga Anda dapat melakukan analisis terperinci sesuai konteks yang mungkin tidak bisa dilakukan hanya dengan field standar.
Sumber data
Zendesk Tickets API, field tags.
Contoh
vip_usernetwork_issueoutage_20231027billing_related
|
|||
|
Tingkat dampak
Severity
|
Besarnya dampak insiden terhadap bisnis. | ||
|
Deskripsi
Tingkat dampak menunjukkan besarnya dampak insiden terhadap bisnis. Biasanya, tingkat dampak dipertimbangkan bersama prioritas untuk menentukan urgensi keseluruhan. Di Zendesk, tingkat dampak umumnya dikonfigurasi sebagai field khusus. Analisis tingkat dampak membantu Anda memahami seberapa kritis insiden yang sedang ditangani. Atribut ini menjadi dimensi penting untuk mengelompokkan data di dashboard seperti 'Pemantauan kepatuhan SLA' dan 'Metrik efektivitas penentuan prioritas'. Dengan membandingkan alur proses pada tiap tingkat dampak, Anda dapat mengetahui apakah insiden berdampak tinggi ditangani dengan kecepatan dan sumber daya yang sesuai.
Mengapa ini penting
Menunjukkan dampak insiden terhadap bisnis, sehingga Anda dapat berfokus pada masalah paling kritis dan memastikan penyelesaiannya berjalan efisien.
Sumber data
Biasanya berupa field khusus. Periksa konfigurasi Ticket Fields di Zendesk Admin Center.
Contoh
1 - Kritis2 - Tinggi3 - Sedang4 - Rendah
|
|||
Aktivitas pengelolaan insiden
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Insiden dibuat
|
Menandai awal siklus insiden, saat tiket baru dibuat di Zendesk. Peristiwa ini tercatat secara eksplisit dalam log audit pembuatan tiket Zendesk dan menjadi titik awal setiap kasus. | ||
|
Mengapa ini penting
Ini adalah aktivitas awal utama. Menganalisis waktu dari peristiwa ini ke peristiwa lainnya penting untuk mengukur durasi siklus tiket secara keseluruhan dan waktu respons awal.
Sumber data
Peristiwa ini tercatat secara eksplisit dalam log audit tiket Zendesk. Setiap tiket baru menghasilkan peristiwa 'Create' dengan stempel waktu terkait.
Pengumpulan data
Diambil langsung dari peristiwa pembuatan tiket dalam log audit.
Jenis peristiwa
explicit
|
|||
|
Insiden diselesaikan
|
Tahap penting ini terjadi saat agen menerapkan solusi dan menandai tiket sebagai 'solved'. Tindakan ini tercatat secara eksplisit sebagai perubahan status dalam log audit tiket. | ||
|
Mengapa ini penting
Ini adalah aktivitas utama penyelesaian dan titik penting untuk mengukur waktu hingga penyelesaian. Jeda antara peristiwa ini dan 'Insiden ditutup' menunjukkan waktu tunggu konfirmasi pengguna atau penutupan otomatis.
Sumber data
Diambil dari log audit tiket melalui peristiwa 'Change' saat nilai baru kolom 'status' menjadi 'solved'.
Pengumpulan data
Diidentifikasi melalui peristiwa 'Change' pada kolom 'status' menjadi 'solved'.
Jenis peristiwa
explicit
|
|||
|
Insiden ditutup
|
Menandai akhir siklus insiden saat tiket ditutup secara permanen. Di Zendesk, penutupan sering terjadi secara otomatis setelah jangka waktu tertentu sejak tiket diselesaikan, dan tercatat sebagai perubahan status terakhir. | ||
|
Mengapa ini penting
Ini adalah aktivitas akhir proses. Durasi total proses dihitung dari 'Insiden dibuat' hingga peristiwa ini, sehingga memberikan gambaran waktu siklus dari awal hingga akhir.
Sumber data
Diambil dari log audit tiket melalui peristiwa 'Change' saat nilai baru kolom 'status' menjadi 'closed'.
Pengumpulan data
Diidentifikasi melalui peristiwa 'Change' pada kolom 'status' menjadi 'closed'.
Jenis peristiwa
explicit
|
|||
|
Status berubah menjadi terbuka
|
Menunjukkan bahwa agen mulai menangani insiden secara aktif. Aktivitas ini biasanya disimpulkan dari perubahan kolom 'status' tiket dari 'new' menjadi 'open', yang menandai dimulainya tahap investigasi dan diagnosis. | ||
|
Mengapa ini penting
Peristiwa ini menandai peralihan dari antrean ke penanganan aktif. Lama tiket berada dalam status 'new' sebelum berubah menjadi 'open' menjadi metrik penting untuk mengukur waktu respons awal.
Sumber data
Disimpulkan dari log audit tiket dengan menemukan peristiwa 'Change' saat nilai baru kolom 'status' adalah 'open' dan nilai sebelumnya 'new'.
Pengumpulan data
Disimpulkan dari perubahan kolom status dari 'new' menjadi 'open'.
Jenis peristiwa
inferred
|
|||
|
Tiket ditugaskan ke agen
|
Aktivitas ini terjadi saat tiket ditugaskan kepada agen tertentu untuk ditangani. Peristiwa ini tercatat secara eksplisit dalam riwayat audit tiket dan menandakan bahwa seorang individu telah mengambil tanggung jawab. | ||
|
Mengapa ini penting
Tahap ini penting untuk mengukur waktu hingga penugasan pertama dan menjadi dasar analisis serah terima, pengerjaan ulang, serta tingkat penyelesaian pada kontak pertama.
Sumber data
Diambil dari log audit tiket saat kolom 'assignee_id' diisi atau diubah. Penugasan pertama menjadi tahap penting dalam penghitungan KPI.
Pengumpulan data
Diidentifikasi melalui peristiwa 'Change' pada kolom 'assignee_id' di log audit tiket.
Jenis peristiwa
explicit
|
|||
|
Tiket ditugaskan ulang
|
Terjadi saat tanggung jawab atas tiket dialihkan dari satu agen atau grup ke agen atau grup lain setelah penugasan awal. Peristiwa ini tercatat secara eksplisit dalam riwayat audit tiket. | ||
|
Mengapa ini penting
Penugasan ulang penting untuk menganalisis serah terima dan pengerjaan ulang. Penugasan ulang yang sering biasanya menunjukkan perutean awal yang keliru, masalah yang rumit, atau hambatan proses.
Sumber data
Diambil dari log audit tiket dengan menemukan peristiwa 'Change' pada kolom 'assignee_id' atau 'group_id' setelah kolom tersebut pertama kali diisi.
Pengumpulan data
Diidentifikasi melalui peristiwa 'Change' berikutnya pada kolom 'assignee_id' atau 'group_id'.
Jenis peristiwa
explicit
|
|||
|
Balasan publik dikirim
|
Menunjukkan komunikasi yang dikirim agen dukungan kepada pengguna akhir. Peristiwa ini tercatat secara eksplisit di Zendesk setiap kali komentar publik ditambahkan ke tiket. | ||
|
Mengapa ini penting
Pelacakan balasan publik penting untuk memahami frekuensi komunikasi dan dapat menjadi bagian penting dari linimasa saat menganalisis keterlambatan konfirmasi pengguna.
Sumber data
Diambil dari data komentar tiket. Komentar dianggap publik jika atribut 'public'-nya bernilai true.
Pengumpulan data
Peristiwa tercatat saat komentar baru dengan 'public: true' ditambahkan ke tiket.
Jenis peristiwa
explicit
|
|||
|
Catatan internal ditambahkan
|
Aktivitas ini menunjukkan kolaborasi internal, saat agen menambahkan catatan pribadi pada tiket untuk anggota tim lainnya. Peristiwa ini tercatat secara eksplisit saat komentar ditandai sebagai bukan publik. | ||
|
Mengapa ini penting
Analisis catatan internal dapat memberi gambaran tentang masalah rumit yang memerlukan kolaborasi. Namun, jumlah catatan yang berlebihan dapat menunjukkan kesenjangan pengetahuan atau inefisiensi proses.
Sumber data
Diambil dari data komentar tiket. Komentar dianggap sebagai catatan internal jika atribut 'public'-nya bernilai false.
Pengumpulan data
Peristiwa tercatat saat komentar baru dengan 'public: false' ditambahkan ke tiket.
Jenis peristiwa
explicit
|
|||
|
Kepuasan pengguna dinilai
|
Menunjukkan saat pengguna akhir memberikan penilaian atas dukungan yang diterima. Peristiwa ini tercatat secara eksplisit di Zendesk setelah tiket diselesaikan. | ||
|
Mengapa ini penting
Analisis penilaian kepuasan memberikan masukan penting tentang kinerja agen dan efektivitas proses, serta menghubungkan metrik proses dengan hasil bagi pelanggan.
Sumber data
Diambil dari data penilaian kepuasan yang terkait dengan tiket. Data ini biasanya mencakup skor ('good' atau 'bad') dan komentar opsional.
Pengumpulan data
Peristiwa tercatat saat penilaian kepuasan dikirim untuk tiket.
Jenis peristiwa
explicit
|
|||
|
Prioritas ditetapkan
|
Tingkat prioritas insiden, misalnya Rendah, Normal, Tinggi, atau Mendesak, ditentukan. Peristiwa ini tercatat secara eksplisit sebagai perubahan dan menentukan tingkat urgensi serta waktu respons yang diperlukan untuk tiket. | ||
|
Mengapa ini penting
Melacak kapan dan bagaimana prioritas ditetapkan penting untuk dashboard 'Metrik Efektivitas Penentuan Prioritas', agar masalah kritis segera ditangani.
Sumber data
Diambil dari peristiwa 'Change' pada kolom 'priority' di log audit tiket. Perubahan berikutnya juga dapat dilacak untuk mengukur KPI Tingkat Perubahan Prioritas.
Pengumpulan data
Diidentifikasi melalui peristiwa 'Change' pada kolom 'priority' di log audit tiket.
Jenis peristiwa
explicit
|
|||
|
Status berubah menjadi menunggu
|
Menunjukkan bahwa proses dijeda sambil menunggu tanggapan dari pemohon. Peristiwa ini disimpulkan dari perubahan kolom 'status' tiket menjadi 'pending'. | ||
|
Mengapa ini penting
Aktivitas ini penting untuk menghitung waktu tunggu konfirmasi pengguna. Waktu yang lama dalam status ini dapat memperpanjang waktu penyelesaian secara keseluruhan dan menunjukkan adanya keterlambatan komunikasi.
Sumber data
Disimpulkan dari log audit tiket dengan menemukan peristiwa 'Change' saat nilai baru kolom 'status' adalah 'pending'.
Pengumpulan data
Disimpulkan dari perubahan kolom status menjadi 'pending'.
Jenis peristiwa
inferred
|
|||
|
Target SLA terlewati
|
Menandai saat tiket gagal memenuhi target Perjanjian Tingkat Layanan, seperti waktu balasan pertama atau waktu penyelesaian. Peristiwa ini dihitung berdasarkan definisi kebijakan SLA dan stempel waktu pembaruan tiket. | ||
|
Mengapa ini penting
Peristiwa ini mendukung pemantauan kepatuhan SLA secara langsung. Mengetahui kapan dan mengapa pelanggaran terjadi merupakan langkah penting untuk meningkatkan keandalan layanan dan kepercayaan pelanggan.
Sumber data
Peristiwa ini dihitung dari data 'sla_policy_metrics' yang terkait dengan tiket, menggunakan stempel waktu 'breached_at' untuk setiap target SLA.
Pengumpulan data
Dihitung dari stempel waktu 'breached_at' dalam data metrik SLA tiket.
Jenis peristiwa
calculated
|
|||
|
Tiket ditugaskan ke grup
|
Menunjukkan perutean atau triase awal insiden ke grup dukungan tertentu. Ini biasanya menjadi langkah pertama dalam menetapkan tanggung jawab dan tercatat sebagai peristiwa perubahan dalam riwayat audit tiket. | ||
|
Mengapa ini penting
Pelacakan penugasan grup membantu menganalisis efisiensi triase awal dan menemukan keterlambatan sebelum tiket diteruskan ke tim yang tepat.
Sumber data
Diambil dari log audit tiket setiap kali kolom 'group_id' diisi atau diubah. Perubahan pertama setelah tiket dibuat merupakan penugasan awal.
Pengumpulan data
Diidentifikasi melalui peristiwa 'Change' pada kolom 'group_id' di log audit tiket.
Jenis peristiwa
explicit
|
|||
Panduan ekstraksi
Siap memulai?
Gunakan templat ini untuk menyiapkan data dengan lebih mudah dan mendapatkan wawasan tentang kinerja pengelolaan insiden. Mulai tingkatkan proses Anda hari ini.
Optimalkan pengelolaan insiden dan selesaikan lebih cepat
Kurangi MTTR sebesar 35%, cegah insiden berulang, dan tingkatkan kepuasan.
Tidak perlu kartu kredit. Mulai melakukan perbaikan dalam hitungan menit.