Templat data pengelolaan permintaan layanan
Templat data pengelolaan permintaan layanan
- Atribut yang disarankan untuk analisis menyeluruh
- Aktivitas utama permintaan layanan yang perlu dilacak
- Panduan ekstraksi data Zendesk Support
Atribut pengelolaan permintaan layanan
| Nama | Deskripsi | ||
|---|---|---|---|
|
Aktivitas
ActivityName
|
Nama aktivitas bisnis atau peristiwa yang terjadi pada suatu permintaan layanan. | ||
|
Deskripsi
Aktivitas menunjukkan langkah atau peristiwa tertentu dalam siklus permintaan layanan, seperti 'Permintaan Layanan Dibuat', 'Permintaan Ditugaskan kepada Agen', atau 'Permintaan Layanan Diselesaikan'. Aktivitas ini berasal dari perubahan yang tercatat dalam log audit tiket Zendesk, yang melacak perubahan pada kolom seperti status, penerima tugas, prioritas, serta penambahan komentar. Analisis aktivitas merupakan inti process mining. Analisis ini membantu memvisualisasikan peta proses, menemukan hambatan di antara langkah-langkah, dan menganalisis pengulangan pekerjaan. Dengan memahami urutan dan frekuensi aktivitas, organisasi dapat menemukan ketidakefisienan dan peluang perbaikan proses.
Mengapa ini penting
Atribut ini menentukan langkah-langkah dalam proses, sehingga peta proses dapat divisualisasikan dan alur, variasi, serta kesesuaian proses dapat dianalisis.
Sumber data
Secara konsep, atribut ini berasal dari peristiwa yang dicatat di Zendesk Ticket Audits API. Contohnya, perubahan kolom 'status' dari 'new' menjadi 'open' dapat dipetakan sebagai aktivitas seperti 'Permintaan Ditriase'.
Contoh
Permintaan layanan dibuatAgen DialihkanPermintaan Layanan Diselesaikan
|
|||
|
ID Permintaan Layanan
ServiceRequestId
|
Pengenal unik untuk setiap tiket permintaan layanan di Zendesk. | ||
|
Deskripsi
ID Permintaan Layanan, yang sering disebut ID Tiket di Zendesk, menjadi kunci utama untuk setiap kasus. ID ini menghubungkan semua aktivitas, komentar, dan perubahan status terkait, sejak permintaan dibuat hingga ditutup. Dengan begitu, seluruh perjalanan satu permintaan dapat ditelusuri dari awal hingga akhir. Dalam analisis process mining, atribut ini menjadi dasar untuk menentukan kasus. Atribut ini memungkinkan rekonstruksi alur proses, identifikasi variasi, dan penghitungan metrik tingkat kasus seperti waktu siklus. Setiap peristiwa dalam kumpulan data harus dikaitkan dengan ID Permintaan Layanan agar konteksnya dalam keseluruhan proses dapat dipahami.
Mengapa ini penting
Pengenal kasus utama ini menghubungkan semua peristiwa dalam perjalanan permintaan layanan, sehingga prosesnya dapat dianalisis dari awal hingga akhir.
Sumber data
Zendesk Tickets API, kolom 'id'.
Contoh
102451024610247
|
|||
|
Waktu Mulai
EventTimestamp
|
Tanggal dan waktu tepat saat aktivitas terjadi. | ||
|
Deskripsi
Stempel Waktu Peristiwa, atau Waktu Mulai, mencatat saat tepat suatu aktivitas berlangsung. Misalnya, atribut ini mencatat waktu agen ditugaskan, balasan publik dikirim, atau status tiket diubah menjadi 'Resolved'. Data waktu ini bersumber dari log audit setiap tiket Zendesk. Atribut ini penting untuk analisis berbasis waktu. Atribut ini digunakan untuk mengurutkan peristiwa secara kronologis, menghitung durasi antaraktivitas, mengukur waktu tunggu, dan menganalisis waktu siklus kasus secara keseluruhan. Atribut ini juga menjadi dasar untuk menemukan hambatan dan menilai kinerja berdasarkan target waktu seperti SLA.
Mengapa ini penting
Stempel waktu ini mengurutkan peristiwa secara kronologis dan penting untuk menganalisis durasi, kinerja, serta hambatan.
Sumber data
Zendesk Ticket Audits API, kolom 'created_at' untuk setiap peristiwa audit.
Contoh
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
|
Pembaruan Data Terakhir
LastDataUpdate
|
Stempel waktu yang menunjukkan kapan data terakhir diperbarui dari sistem sumber. | ||
|
Deskripsi
Atribut ini mencatat tanggal dan waktu ekstraksi data terbaru dari Zendesk Support. Informasi ini menunjukkan seberapa baru data yang dianalisis, sehingga pengguna mengetahui apakah tampilan proses sudah diperbarui. Informasi ini penting untuk pemantauan berkelanjutan dan penyajian data di dashboard. Analis dan pengguna bisnis dapat mengetahui apakah data yang dilihat mendekati waktu nyata atau berasal dari periode sebelumnya. Hal ini memengaruhi keandalan kesimpulan.
Mengapa ini penting
Menunjukkan seberapa baru data, sehingga pengguna tahu kapan analisis terakhir diperbarui.
Sumber data
Kolom metadata ini dibuat dan ditambahkan ke kumpulan data saat data diekstrak.
Contoh
2023-10-27T08:00:00Z
|
|||
|
Sistem Sumber
SourceSystem
|
Menunjukkan sistem asal data yang diekstrak. | ||
|
Deskripsi
Atribut ini menunjukkan asal data permintaan layanan. Dalam tampilan proses ini, nilainya selalu 'Zendesk Support', yang menandakan bahwa sistem tersebut menjadi sumber utama untuk semua aktivitas manajemen layanan. Jika lingkungan kerja menggunakan beberapa sistem terintegrasi, kolom ini penting untuk melacak asal-usul data dan memecahkan masalah. Kolom ini memastikan analisis mencakup sistem yang dimaksud dan membantu membedakan data saat digabungkan dari berbagai sumber.
Mengapa ini penting
Menunjukkan sistem asal data, membantu melacak asal-usul data dan mencegah kebingungan saat data dari beberapa sistem digabungkan.
Sumber data
Nilai statis ('Zendesk Support') yang ditambahkan saat ekstraksi dan transformasi data.
Contoh
Zendesk Support
|
|||
|
Jenis Layanan
ServiceType
|
Kategori atau jenis permintaan layanan, misalnya Insiden, Pertanyaan, Masalah, atau Tugas. | ||
|
Deskripsi
Jenis Layanan mengelompokkan permintaan berdasarkan sifatnya. Zendesk menggunakan kolom 'type' untuk membedakan berbagai jenis interaksi dukungan. Klasifikasi awal ini membantu mengarahkan tiket ke tim yang tepat dan menerapkan proses yang sesuai. Atribut ini penting untuk pemfilteran dan perbandingan. Analis dapat memeriksa alur proses untuk berbagai jenis permintaan, yang sering kali memiliki jalur penyelesaian dan SLA berbeda. Atribut ini menjadi dimensi utama dalam dashboard Kinerja Agen & Tim untuk melihat siapa yang paling tepat menangani jenis permintaan tertentu.
Mengapa ini penting
Mengelompokkan permintaan agar berbagai proses dapat dianalisis secara terpisah, misalnya insiden dan pertanyaan yang mengikuti jalur berbeda.
Sumber data
Zendesk Tickets API, kolom 'type'.
Contoh
pertanyaaninsidenmasalahtugas
|
|||
|
Nama Agen
AgentName
|
Nama agen yang menangani permintaan layanan saat peristiwa terjadi. | ||
|
Deskripsi
Atribut ini menunjukkan agen dukungan yang bertanggung jawab menangani permintaan layanan. Agen yang ditugaskan dapat berubah beberapa kali selama siklus tiket, dan kolom ini mencatat siapa yang bertanggung jawab pada setiap langkah. Nama Agen penting untuk analisis kinerja. Atribut ini memungkinkan data difilter dan dikelompokkan untuk menilai pembagian beban kerja, waktu penyelesaian per agen, dan frekuensi pengalihan. Informasi ini membantu menyusun dashboard Kinerja Agen & Tim dan memahami kontribusi setiap orang terhadap efisiensi proses secara keseluruhan.
Mengapa ini penting
Atribut ini penting untuk menganalisis kinerja agen, pembagian beban kerja, dan dampak pengalihan terhadap waktu penyelesaian.
Sumber data
Zendesk Users API, dengan menggabungkan 'assignee_id' dari respons Tickets API.
Contoh
Jane DoeJohn SmithEmily Jones
|
|||
|
Prioritas Permintaan
RequestPriority
|
Tingkat prioritas permintaan layanan, seperti Rendah, Normal, Tinggi, atau Mendesak. | ||
|
Deskripsi
Prioritas Permintaan menunjukkan tingkat urgensi suatu permintaan layanan. Tingkat ini biasanya menentukan target waktu penyelesaian dan kebijakan SLA yang berlaku untuk tiket. Sistem atau pengguna dapat menetapkan prioritas sejak awal, lalu agen dapat mengubahnya selama tiket ditangani. Atribut ini penting untuk pengelompokan dan analisis akar masalah. Atribut ini membantu membandingkan waktu penyelesaian tiket berprioritas tinggi dan rendah, serta menjadi dimensi utama dalam dashboard 'Tren Eskalasi Permintaan Layanan' dan 'Kepatuhan SLA'.
Mengapa ini penting
Memungkinkan permintaan dikelompokkan berdasarkan urgensi. Ini penting untuk menganalisis kepatuhan SLA dan memastikan masalah kritis ditangani dengan cepat.
Sumber data
Zendesk Tickets API, kolom 'priority'.
Contoh
RendahNormalTinggiMendesak
|
|||
|
Saluran Permintaan
RequestChannel
|
Saluran yang digunakan untuk mengajukan permintaan layanan, misalnya email, formulir web, atau telepon. | ||
|
Deskripsi
Atribut ini menunjukkan sumber pengajuan permintaan layanan. Zendesk mencatat cara tiket dibuat, baik melalui email, portal web, integrasi API, chat, maupun saluran lainnya. Informasi ini memberi konteks tentang cara pelanggan menghubungi tim dukungan. Saluran Permintaan menjadi dimensi penting untuk analisis. Atribut ini mendukung dashboard 'Efisiensi Saluran Permintaan' dengan membandingkan waktu penyelesaian, tingkat kepuasan, dan tingkat pekerjaan ulang di berbagai saluran. Hasilnya dapat membantu bisnis meningkatkan saluran dukungan dan mengarahkan pengguna ke saluran yang paling efisien.
Mengapa ini penting
Membantu menganalisis efisiensi dan hasil dari berbagai saluran dukungan pelanggan, sehingga perbaikan dapat diarahkan dengan tepat.
Sumber data
Zendesk Tickets API, objek 'via' dan properti 'channel'.
Contoh
webemailapichat
|
|||
|
Status Permintaan
RequestStatus
|
Status permintaan layanan saat peristiwa terjadi, misalnya Baru, Terbuka, atau Menunggu. | ||
|
Deskripsi
Status Permintaan menunjukkan keadaan tiket pada waktu tertentu. Zendesk memiliki beberapa status standar, seperti New, Open, Pending, On-hold, Solved, dan Closed, yang menandai perkembangan permintaan selama siklusnya. Perubahan pada kolom ini menjadi pemicu utama pembuatan aktivitas dalam log peristiwa. Menganalisis waktu yang dihabiskan dalam setiap status merupakan bagian penting dari analisis hambatan. Analisis ini membantu menemukan tiket yang tertahan, misalnya terlalu lama berstatus 'Pending' atau 'On-hold'. Memahami perpindahan status juga penting untuk menemukan pengulangan pekerjaan.
Mengapa ini penting
Melacak status penting untuk memahami perkembangan permintaan dan mengetahui waktu yang dihabiskan dalam keadaan menunggu atau aktif.
Sumber data
Zendesk Tickets API, kolom 'status'.
Contoh
BaruTerbukaMenungguDiselesaikanDitutup
|
|||
|
Tag Tiket
TicketTags
|
Daftar tag yang diterapkan pada permintaan layanan untuk pengelompokan dan perutean. | ||
|
Deskripsi
Tag adalah label fleksibel yang dapat ditambahkan agen secara manual ke tiket atau diterapkan otomatis melalui aturan bisnis. Tag memberi konteks atau kategori khusus yang tidak tercakup dalam kolom standar seperti Jenis atau Prioritas. Tag sangat berguna dalam analisis process mining. Tag dapat digunakan untuk memfilter skenario tertentu, melacak alur kerja khusus, atau menemukan akar masalah. Misalnya, tag 'VIP' dapat digunakan untuk menganalisis proses bagi pelanggan utama, sedangkan tag 'product_bug' dapat digunakan untuk menelusuri siklus laporan kerusakan.
Mengapa ini penting
Memberi cara fleksibel untuk mengelompokkan dan menelaah data, sehingga subproses tertentu atau atribut tiket yang tidak tercatat di kolom lain dapat dianalisis lebih mendalam.
Sumber data
Zendesk Tickets API, kolom 'tags'. Kolom ini berupa array string.
Contoh
sales_inquirybilling_issuefeature_requestvip_customer
|
|||
|
Tim yang Ditugaskan
AssignedTeam
|
Tim atau grup dukungan yang ditugaskan untuk menangani permintaan layanan. | ||
|
Deskripsi
Atribut ini menunjukkan tim atau grup dalam organisasi dukungan yang bertanggung jawab atas permintaan layanan. Di Zendesk, tim atau grup ini disebut 'Groups'. Tiket sering kali ditugaskan ke grup terlebih dahulu sebelum ditangani oleh agen tertentu. Analisis berdasarkan Tim yang Ditugaskan penting untuk memahami kinerja dan beban kerja tiap tim. Analisis ini membantu menjawab pertanyaan seperti tim mana yang menangani jenis permintaan tertentu, berapa rata-rata waktu penyelesaiannya, dan seberapa baik tim memenuhi SLA. Atribut ini menjadi dimensi utama dalam dashboard Kinerja Agen & Tim.
Mengapa ini penting
Memungkinkan analisis kinerja tim, pemerataan beban kerja, dan efisiensi perutean antargrup dukungan.
Sumber data
Zendesk Groups API, dengan menggabungkan 'group_id' dari respons Tickets API.
Contoh
Dukungan Tingkat 1Dukungan TeknisPenagihan
|
|||
|
Apakah diselesaikan pada kontak pertama
IsFirstContactResolution
|
Penanda yang menunjukkan apakah permintaan diselesaikan oleh agen pertama yang ditugaskan, tanpa pengalihan atau balasan dari pemohon. | ||
|
Deskripsi
Penyelesaian pada kontak pertama (FCR) adalah metrik penting yang menunjukkan bahwa masalah pelanggan selesai dalam satu interaksi. Atribut hasil perhitungan ini berupa penanda boolean yang bernilai benar jika tiket diselesaikan oleh agen pertama yang ditugaskan, tanpa pengalihan dan hanya dengan satu balasan agen. Atribut ini mendukung KPI 'Tingkat Penyelesaian pada Kontak Pertama'. Menganalisis karakteristik kasus FCR dapat menjadi acuan untuk meningkatkan proses. Sebaliknya, analisis kasus yang tidak mencapai FCR dapat menunjukkan peluang untuk meningkatkan pelatihan agen, memperbaiki artikel basis pengetahuan, atau menyempurnakan triase awal.
Mengapa ini penting
Mengukur kemampuan menyelesaikan masalah secara efisien dalam satu interaksi. Hal ini sangat memengaruhi kepuasan pelanggan dan efisiensi operasional.
Sumber data
Atribut ini memerlukan perhitungan yang kompleks. Anda perlu menganalisis event log tiket untuk memeriksa pengalihan agen dan jumlah balasan publik dari agen.
Contoh
truefalse
|
|||
|
Apakah pengerjaan ulang
IsRework
|
Penanda bernilai benar jika permintaan layanan dibuka kembali setelah diselesaikan. | ||
|
Deskripsi
Penanda boolean ini menunjukkan kasus yang mengalami pengerjaan ulang. Permintaan layanan biasanya dianggap mengalami pengerjaan ulang jika statusnya berubah dari 'Diselesaikan' kembali ke status terbuka. Artinya, penyelesaian awal belum memadai dan pelanggan harus menghubungi Anda lagi untuk masalah yang sama. Atribut ini penting untuk menghitung KPI 'Tingkat Pengerjaan Ulang Permintaan Layanan' dan mendukung dashboard 'Analisis Pengerjaan Ulang dan Aktivitas Pembukaan Kembali'. Dengan menandai kasus pengerjaan ulang, analis dapat memisahkan alur proses yang tidak efisien, mencari penyebab tiket dibuka kembali, dan meningkatkan penyelesaian pada kontak pertama.
Mengapa ini penting
Menunjukkan kegagalan proses saat masalah belum benar-benar terselesaikan. Hal ini menyoroti masalah kualitas dan efisiensi yang berdampak langsung pada kepuasan pelanggan.
Sumber data
Dihitung dengan menganalisis urutan status tiket di Zendesk Ticket Audits API. Perubahan dari 'solved' ke 'open' menunjukkan pengerjaan ulang.
Contoh
truefalse
|
|||
|
Apakah SLA dilanggar
IsSlaBreached
|
Penanda yang menunjukkan apakah permintaan layanan melanggar salah satu target SLA. | ||
|
Deskripsi
Penanda boolean atau kategori ini menunjukkan hasil SLA untuk sebuah tiket. Nilainya dapat berupa 'Terpenuhi', 'Dilanggar', atau 'Aktif'. Hasil ditentukan dengan membandingkan waktu respons atau penyelesaian aktual dengan target dalam kebijakan SLA yang berlaku. Atribut ini penting untuk dashboard 'Analisis Kepatuhan dan Pelanggaran SLA'. Anda dapat dengan mudah menghitung dan memvisualisasikan tiket yang patuh dan tidak patuh. Selanjutnya, analisis dapat berfokus pada karakteristik proses tiket yang melanggar SLA untuk menemukan penyebabnya, seperti waktu tunggu yang lama atau pengalihan yang berlebihan.
Mengapa ini penting
Mengukur langsung kinerja terhadap komitmen tingkat layanan, yang menjadi indikator penting kualitas layanan dan kepuasan pelanggan.
Sumber data
Berasal dari Zendesk Ticket Metrics API, yang menyediakan informasi status SLA untuk setiap tiket.
Contoh
TerpenuhiDilanggarAktif
|
|||
|
Jumlah pengalihan agen
AgentReassignmentCount
|
Jumlah total pengalihan permintaan dari satu agen ke agen lain. | ||
|
Deskripsi
Penghitung ini bertambah setiap kali kolom 'assignee_id' pada tiket berubah. Banyaknya pengalihan pada satu tiket dapat menandakan berbagai masalah proses, seperti penyaluran awal yang keliru, kurangnya pengetahuan agen, atau permintaan yang terlalu rumit untuk ditangani satu agen. Metrik ini penting untuk mengukur efisiensi proses dan mendukung KPI 'Tingkat Pengalihan Agen'. Analisis kasus dengan banyak pengalihan dapat menunjukkan peluang untuk memperbaiki aturan penyaluran, pelatihan agen, atau sumber daya basis pengetahuan. Dengan begitu, tiket bisa lebih cepat ditangani oleh orang yang tepat.
Mengapa ini penting
Membantu mengukur serah terima internal dan menemukan hambatan dalam proses. Tingkat pengalihan yang tinggi sering menyebabkan keterlambatan dan inefisiensi.
Sumber data
Dihitung dengan menghitung perubahan 'assignee_id' pada Zendesk Ticket Audits API untuk setiap tiket.
Contoh
013
|
|||
|
Nama Kebijakan SLA
SlaPolicyName
|
Nama kebijakan Perjanjian Tingkat Layanan (SLA) yang diterapkan pada permintaan. | ||
|
Deskripsi
Atribut ini menunjukkan kebijakan SLA yang menentukan target waktu respons dan penyelesaian permintaan layanan. Kebijakan biasanya ditentukan berdasarkan faktor seperti prioritas dan jenis permintaan, atau tingkat langganan pelanggan. Informasi kebijakan SLA yang berlaku penting untuk dashboard 'Analisis Kepatuhan dan Pelanggaran SLA'. Kebijakan ini memberi konteks untuk menilai kinerja, karena setiap kebijakan memiliki target berbeda. Dengan begitu, Anda dapat menilai secara adil dan akurat apakah tiket memenuhi sasaran tingkat layanan yang berlaku.
Mengapa ini penting
Memberi konteks untuk analisis SLA dengan menunjukkan target yang digunakan untuk mengukur permintaan, sehingga pelaporan kepatuhan lebih akurat.
Sumber data
Zendesk Ticket Metrics API. Data SLA biasanya terkait dengan metrik tiket.
Contoh
Mendesak, respons dalam 1 jamStandar, penyelesaian dalam 24 jamSLA pelanggan premium
|
|||
|
Nama Pemohon
RequestorName
|
Nama pengguna akhir atau pelanggan yang mengajukan permintaan layanan. | ||
|
Deskripsi
Atribut ini menunjukkan orang yang mengajukan permintaan layanan. Dengan mengaitkan permintaan ke pelanggan tertentu, proses dukungan dapat dilihat dari sudut pandang pengguna. Dalam analisis proses, pemohon dapat digunakan untuk melihat pola pada pelanggan atau segmen pelanggan tertentu. Misalnya, Anda dapat memeriksa apakah pelanggan tertentu mengalami waktu penyelesaian lebih lama atau lebih sering mengalami pekerjaan ulang. Hal ini dapat menunjukkan masalah pada produk atau layanan yang mereka gunakan.
Mengapa ini penting
Menghubungkan proses dengan pelanggan, sehingga masalah khusus pelanggan, permintaan berulang, dan tingkat kepuasan dapat dianalisis.
Sumber data
Zendesk Users API, dengan menggabungkan 'requester_id' dari respons Tickets API.
Contoh
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
Nilai Kepuasan
SatisfactionRating
|
Skor kepuasan yang diberikan pemohon setelah tiket diselesaikan. | ||
|
Deskripsi
Atribut ini mencatat umpan balik pelanggan tentang pengalaman mereka menerima dukungan. Biasanya, umpan balik dikumpulkan melalui survei setelah tiket ditandai sebagai selesai. Penilaian umum mencakup 'Good' atau 'Bad', terkadang disertai komentar. Nilai Kepuasan merupakan metrik hasil yang penting. Dengan menghubungkan pola proses dan skor kepuasan, Anda dapat mengetahui perilaku proses yang membuat pelanggan puas atau tidak puas. Misalnya, analisis dapat menunjukkan bahwa seringnya pengalihan atau lamanya waktu penyelesaian berkaitan erat dengan penilaian kepuasan yang buruk.
Mengapa ini penting
Menghubungkan pelaksanaan proses dengan hasil bagi pelanggan, sehingga Anda dapat mengetahui perilaku proses yang mendorong kepuasan pelanggan.
Sumber data
Zendesk Tickets API, kolom 'satisfaction_rating.score' atau 'satisfaction_rating.reason'.
Contoh
BaikBurukDitawarkan
|
|||
|
Organisasi Pemohon
RequestorOrganization
|
Organisasi atau perusahaan tempat pemohon bekerja. | ||
|
Deskripsi
Atribut ini menghubungkan permintaan layanan dengan organisasi pelanggan tertentu. Atribut ini sangat relevan untuk dukungan B2B, karena perjanjian tingkat layanan dan kontrak dukungan sering ditetapkan di tingkat organisasi. Analisis berdasarkan organisasi memberikan gambaran kinerja dukungan di tingkat perusahaan. Analisis ini dapat membantu menemukan organisasi yang mengajukan banyak tiket, mengalami masalah berulang, atau memiliki skor kepuasan rendah. Informasi ini berguna untuk pengelolaan akun dan memahami tren kondisi pelanggan secara lebih luas.
Mengapa ini penting
Memungkinkan analisis layanan B2B dengan mengelompokkan permintaan berdasarkan perusahaan. Ini penting untuk mengelola hubungan pelanggan dan SLA di tingkat organisasi.
Sumber data
Zendesk Organizations API, dengan menggabungkan 'organization_id' dari respons Tickets API.
Contoh
Acme CorporationGlobal Tech Inc.Innovate Solutions
|
|||
|
Waktu Selesai
EndTime
|
Tanggal dan waktu tepat saat aktivitas selesai. | ||
|
Deskripsi
Waktu Selesai menandai saat suatu aktivitas berakhir. Untuk banyak peristiwa di Zendesk, durasinya seketika, sehingga Waktu Selesai sama dengan Waktu Mulai. Namun, untuk aktivitas berbasis status seperti 'Permintaan Ditangguhkan', Waktu Selesai adalah saat tiket tidak lagi ditangguhkan. Atribut ini penting untuk menghitung durasi aktivitas tertentu, yang diperlukan untuk menganalisis hambatan. Dengan membandingkan Waktu Mulai dan Waktu Selesai suatu aktivitas, waktu pemrosesannya dapat diukur secara langsung. Ini membantu menemukan langkah yang paling banyak menyita waktu.
Mengapa ini penting
Memungkinkan penghitungan durasi setiap aktivitas, yang penting untuk menemukan hambatan proses dan mengukur efisiensi tiap langkah.
Sumber data
Untuk peristiwa yang berlangsung seketika, nilainya sering sama dengan StartTime. Untuk durasi status, nilainya adalah stempel waktu peristiwa berikutnya yang mengubah status.
Contoh
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
Aktivitas pengelolaan permintaan layanan
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Balasan Publik Dikirim
|
Aktivitas ini menandai komunikasi yang dikirim agen kepada pemohon. Data mencatatnya sebagai peristiwa 'Comment' eksplisit pada tiket Zendesk, dengan atribut 'public' bernilai true. | ||
|
Mengapa ini penting
Peristiwa ini penting untuk menganalisis frekuensi komunikasi, mengukur waktu respons agen, dan mengetahui jumlah interaksi yang diperlukan hingga permintaan selesai.
Sumber data
Ini adalah peristiwa 'Comment' eksplisit dalam data tiket. Detail peristiwa mencakup atribut 'public: true', yang membedakannya dari catatan internal.
Pengumpulan data
Diambil dari peristiwa 'Comment' pada tiket dengan penanda 'public' bernilai true.
Jenis peristiwa
explicit
|
|||
|
Permintaan ditugaskan kepada agen
|
Aktivitas ini terjadi saat permintaan layanan pertama kali ditugaskan kepada agen tertentu. Aktivitas ini disimpulkan dari peristiwa 'Change' dalam log audit tiket, ketika kolom 'assignee_id' diisi dari nilai null atau ID grup. | ||
|
Mengapa ini penting
Aktivitas ini menandai dimulainya penanganan aktif oleh agen. Data ini penting untuk mengukur waktu respons awal, jeda sebelum penugasan pertama, dan pembagian beban kerja agen.
Sumber data
Disimpulkan dari peristiwa 'Change' pertama pada kolom 'assignee_id' dalam log audit tiket, saat ID pengguna tertentu ditetapkan.
Pengumpulan data
Disimpulkan dari peristiwa perubahan pertama yang menetapkan kolom 'assignee_id' kepada agen.
Jenis peristiwa
inferred
|
|||
|
Permintaan layanan dibuat
|
Menandai awal siklus permintaan layanan, saat pemohon mengirimkan tiket baru melalui kanal apa pun. Peristiwa ini tercatat sebagai peristiwa 'Create' dalam log audit tiket Zendesk dan menjadi penanda waktu mulai proses yang pasti. | ||
|
Mengapa ini penting
Aktivitas ini menjadi peristiwa awal utama untuk setiap permintaan layanan. Data ini penting untuk menghitung waktu siklus dari awal hingga akhir dan menganalisis volume permintaan yang masuk.
Sumber data
Peristiwa ini tercatat sebagai jenis peristiwa 'Create' dalam log audit tiket Zendesk. Stempel waktunya menunjukkan waktu pembuatan tiket permintaan layanan.
Pengumpulan data
Diambil langsung dari peristiwa 'Create' dalam log audit tiket.
Jenis peristiwa
explicit
|
|||
|
Permintaan Layanan Dibuka Kembali
|
Terjadi saat pemohon membalas permintaan berstatus 'solved', sehingga statusnya otomatis berubah kembali menjadi 'open'. Ini menandakan solusi yang diberikan belum memadai. | ||
|
Mengapa ini penting
Aktivitas ini menjadi indikator utama pekerjaan ulang. Analisis frekuensinya membantu mengukur kualitas penyelesaian dan menemukan penyebab ketidakpuasan pelanggan.
Sumber data
Disimpulkan dari peristiwa 'Change' pada kolom 'status' di log audit tiket, saat nilai sebelumnya 'solved' dan nilai barunya 'open'.
Pengumpulan data
Disimpulkan dari perubahan status 'solved' menjadi 'open'.
Jenis peristiwa
inferred
|
|||
|
Permintaan Layanan Diselesaikan
|
Aktivitas ini menandai saat agen memberikan solusi dan mengubah status tiket menjadi 'solved'. Dari sisi agen, permintaan dianggap selesai, tetapi pemohon masih dapat membukanya kembali. | ||
|
Mengapa ini penting
Ini adalah tonggak penting yang menandai berakhirnya pekerjaan aktif agen. Waktu yang diperlukan untuk mencapai status ini menjadi ukuran utama efisiensi penyelesaian.
Sumber data
Disimpulkan dari peristiwa 'Change' pada kolom 'status' di log audit tiket, saat nilai barunya adalah 'solved'.
Pengumpulan data
Disimpulkan dari peristiwa 'Change' di log audit saat status berubah menjadi 'solved'.
Jenis peristiwa
inferred
|
|||
|
Permintaan Layanan Ditutup
|
Menandai penutupan akhir permintaan layanan yang tidak dapat dibatalkan. Setelah berstatus 'solved' selama jangka waktu tertentu, tiket otomatis berubah menjadi 'closed' dan tidak dapat dibuka kembali. | ||
|
Mengapa ini penting
Aktivitas ini menandai berakhirnya proses permintaan layanan secara definitif. Aktivitas ini menjadi titik akhir untuk menghitung durasi kasus secara keseluruhan.
Sumber data
Disimpulkan dari peristiwa 'Change' pada kolom 'status' di log audit tiket, saat nilai barunya adalah 'closed'.
Pengumpulan data
Disimpulkan dari peristiwa 'Change' di log audit saat status berubah menjadi 'closed'.
Jenis peristiwa
inferred
|
|||
|
Target SLA Terlewati
|
Aktivitas ini menandai waktu ketika permintaan layanan tidak memenuhi target SLA yang ditetapkan, seperti waktu balasan pertama atau waktu penyelesaian. Zendesk mencatatnya sebagai peristiwa eksplisit saat target terlewati. | ||
|
Mengapa ini penting
Peristiwa ini penting untuk memantau kepatuhan dan menjadi masukan utama bagi KPI Tingkat Kepatuhan SLA. Peristiwa ini menunjukkan dengan tepat kapan komitmen layanan tidak terpenuhi.
Sumber data
Diambil dari peristiwa 'SLABreach' dalam peristiwa tiket Zendesk atau log audit. Peristiwa ini menyebutkan metrik SLA yang terlewati.
Pengumpulan data
Diidentifikasi melalui peristiwa 'SLABreach' eksplisit dalam data tiket.
Jenis peristiwa
explicit
|
|||
|
Agen Dialihkan
|
Menandai pengalihan tanggung jawab atas permintaan layanan dari satu agen ke agen lain. Peristiwa ini disimpulkan dari peristiwa 'Change' berikutnya pada kolom 'assignee_id' setelah penugasan awal. | ||
|
Mengapa ini penting
Melacak pengalihan agen penting untuk menghitung KPI Tingkat Pengalihan Agen. KPI ini membantu menemukan ketidakefisienan proses, kesalahan perutean, atau kesenjangan pengetahuan.
Sumber data
Disimpulkan dari peristiwa 'Change' pada kolom 'assignee_id' di log audit tiket, kecuali peristiwa penugasan pertama untuk tiket tersebut.
Pengumpulan data
Disimpulkan dari peristiwa 'Change' kedua dan seterusnya pada kolom 'assignee_id'.
Jenis peristiwa
inferred
|
|||
|
Catatan Internal Ditambahkan
|
Agen menambahkan catatan atau komentar internal pada permintaan layanan. Catatan ini hanya dapat dilihat oleh agen lain. Data mencatatnya sebagai peristiwa 'Comment' dengan atribut 'public' bernilai false. | ||
|
Mengapa ini penting
Melacak catatan internal memberi gambaran tentang kolaborasi antaragen atau tim. Kolaborasi ini bisa menjadi sumber keterlambatan atau membantu penyelesaian masalah dengan lebih efisien.
Sumber data
Ini adalah peristiwa 'Comment' eksplisit dalam data tiket. Detail peristiwa mencakup atribut 'public: false', yang menandakan bahwa komentar tersebut adalah catatan internal.
Pengumpulan data
Diambil dari peristiwa 'Comment' pada tiket dengan penanda 'public' bernilai false.
Jenis peristiwa
explicit
|
|||
|
Permintaan Dieskalasikan
|
Menandai eskalasi resmi permintaan layanan ke tingkat dukungan yang lebih tinggi, tim lain, atau manajemen. Biasanya, peristiwa ini disimpulkan dari perubahan grup yang ditugaskan pada tiket atau perubahan kolom khusus untuk melacak eskalasi. | ||
|
Mengapa ini penting
Memantau eskalasi membantu menemukan permintaan yang rumit, kebutuhan pelatihan bagi agen lini depan, dan masalah sistemik yang memerlukan penanganan tingkat lebih tinggi.
Sumber data
Ini bukan peristiwa standar. Peristiwa ini harus disimpulkan dari peristiwa 'Change' pada kolom 'group_id' ke grup eskalasi, atau dari perubahan kolom tiket khusus yang digunakan untuk melacak eskalasi.
Pengumpulan data
Disimpulkan dari perubahan 'group_id' atau kolom khusus 'escalation'.
Jenis peristiwa
inferred
|
|||
|
Permintaan Ditangguhkan
|
Aktivitas ini terjadi saat status permintaan layanan berubah menjadi 'on-hold'. Biasanya, ini berarti agen sedang menunggu informasi dari pemohon atau pihak ketiga. Peristiwa ini disimpulkan dari perubahan status. | ||
|
Mengapa ini penting
Dengan aktivitas ini, waktu tunggu di luar kendali langsung tim dukungan dapat dipisahkan dan diukur. Hasilnya, waktu penanganan oleh agen terlihat lebih akurat.
Sumber data
Disimpulkan dari peristiwa 'Change' pada kolom 'status' di log audit tiket, saat nilai barunya adalah 'on-hold'.
Pengumpulan data
Disimpulkan dari peristiwa 'Change' di log audit saat status berubah menjadi 'on-hold'.
Jenis peristiwa
inferred
|
|||
|
Prioritas diubah
|
Menunjukkan bahwa tingkat prioritas permintaan layanan, seperti 'Rendah', 'Normal', 'Tinggi', atau 'Mendesak', telah diperbarui. Perubahan ini tercatat sebagai peristiwa 'Change' pada kolom 'priority' dalam log audit tiket. | ||
|
Mengapa ini penting
Analisis perubahan prioritas membantu menemukan permintaan yang tingkat urgensinya meningkat seiring waktu dan menilai apakah prioritas dikelola dengan baik.
Sumber data
Dicatat sebagai peristiwa 'Change' pada kolom 'priority' di log audit tiket Zendesk, yang menampilkan nilai sebelumnya dan nilai baru.
Pengumpulan data
Disimpulkan dari peristiwa 'Change' pada kolom 'priority' di log audit.
Jenis peristiwa
inferred
|
|||
|
Target SLA diterapkan
|
Menandai saat kebijakan perjanjian tingkat layanan (SLA) diterapkan pada tiket permintaan layanan. Peristiwa ini dicatat secara eksplisit ketika properti tiket memenuhi kondisi kebijakan SLA yang aktif. | ||
|
Mengapa ini penting
Melacak waktu penerapan SLA penting untuk memantau kepatuhan, menganalisis potensi pelanggaran, dan memahami tenggat layanan yang diharapkan untuk berbagai jenis permintaan.
Sumber data
Diambil dari peristiwa 'SLAPolicyApplied' dalam peristiwa tiket atau log audit Zendesk. Peristiwa ini menunjukkan kebijakan yang cocok.
Pengumpulan data
Dikenali melalui peristiwa 'SLAPolicyApplied' yang tercatat secara eksplisit dalam data tiket.
Jenis peristiwa
explicit
|
|||
Panduan ekstraksi
Siap memulai?
Mulai optimalkan proses permintaan layanan Anda hari ini. Gunakan templat data ini untuk menemukan hambatan dan meningkatkan efisiensi di Zendesk Support.
Optimalkan pengelolaan permintaan layanan. Kurangi keterlambatan sekarang.
Atasi pemenuhan yang lambat dan frustrasi pengguna. Capai otomatisasi 70%.
Tidak perlu kartu kredit. Penyiapan cepat.