Templat data pengelolaan insiden

Zendesk Support
Templat data pengelolaan insiden

Templat data pengelolaan insiden

Templat ini merangkum data penting yang diperlukan untuk menganalisis proses pengelolaan insiden. Templat ini menjelaskan atribut utama yang perlu dikumpulkan, aktivitas penting yang perlu dilacak, serta cara praktis mengekstrak data dari Zendesk Support. Gunakan templat ini agar proyek process mining Anda dimulai dengan kumpulan data yang lengkap dan andal.
  • Atribut yang disarankan untuk dikumpulkan
  • Aktivitas utama untuk dilacak dalam pemetaan proses
  • Panduan praktis untuk mengekstrak data
Baru mengenal log peristiwa? Pelajari cara membuat log peristiwa process mining.

Atribut pengelolaan insiden

Berikut kolom data yang disarankan untuk disertakan dalam log peristiwa agar proses pengelolaan insiden dapat dianalisis secara menyeluruh.
5 Wajib 7 Disarankan 11 Opsional
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
Wajib Disarankan Opsional

Aktivitas pengelolaan insiden

Catat langkah dan tonggak penting proses ini dalam log peristiwa agar proses dapat ditemukan dan dianalisis dengan akurat.
6 Disarankan 7 Opsional
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
Disarankan Opsional

Panduan ekstraksi

Cara mengambil data dari Zendesk Support

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.

Mulai uji coba gratis

Tidak perlu kartu kredit. Mulai melakukan perbaikan dalam hitungan menit.