Templat data layanan pelanggan Anda
Templat data layanan pelanggan Anda
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak dalam proses layanan pelanggan
- Panduan ekstraksi data dari Zendesk Support
Atribut layanan pelanggan
| Nama | Deskripsi | ||
|---|---|---|---|
|
Permintaan layanan
ServiceRequest
|
Pengenal unik untuk setiap permintaan layanan pelanggan, yang juga dikenal sebagai tiket atau kasus. | ||
|
Deskripsi
Permintaan layanan adalah ID kasus utama yang menghubungkan semua aktivitas terkait satu pertanyaan atau masalah pelanggan, mulai dari pembuatan hingga penyelesaian akhir. Setiap interaksi, pembaruan, atau tindakan internal terkait dengan ID unik ini. Dalam process mining, analisis peristiwa yang dikelompokkan berdasarkan permintaan layanan memberikan gambaran menyeluruh tentang perjalanan layanan pelanggan. ID ini menjadi dasar untuk menghitung metrik utama, seperti total waktu penyelesaian, menemukan penyimpangan proses, dan memahami siklus setiap masalah pelanggan.
Mengapa ini penting
Ini adalah ID kasus utama yang menghubungkan semua langkah proses, sehingga setiap perjalanan layanan pelanggan dapat direkonstruksi dan dianalisis.
Sumber data
Zendesk Tickets API, kolom
Contoh
102451287415332
|
|||
|
Waktu mulai
StartTime
|
Stempel waktu yang menunjukkan kapan suatu aktivitas atau peristiwa dimulai. | ||
|
Deskripsi
Waktu mulai, atau stempel waktu peristiwa, mencatat tanggal dan waktu persis terjadinya aktivitas tertentu. Contohnya, waktu komentar pelanggan ditambahkan, agen ditugaskan, atau status tiket diubah menjadi 'Resolved'. Stempel waktu ini menjadi dasar process mining karena menentukan urutan kronologis peristiwa. Data ini digunakan untuk menghitung durasi antaraktivitas, mengukur waktu siklus, menganalisis kinerja terhadap SLA, dan memahami dinamika waktu dalam proses layanan.
Mengapa ini penting
Stempel waktu ini penting untuk mengurutkan peristiwa, menghitung durasi, dan menganalisis lini masa proses permintaan layanan.
Sumber data
Zendesk Ticket Audits API, kolom
Contoh
2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
|
|||
|
Nama aktivitas
ActivityName
|
Nama peristiwa atau tugas tertentu yang terjadi selama siklus permintaan layanan. | ||
|
Deskripsi
Nama aktivitas menjelaskan satu langkah atau tahap penting dalam proses layanan pelanggan, seperti 'Permintaan layanan dibuat', 'Permintaan ditugaskan kepada agen', atau 'Permintaan layanan diselesaikan'. Setiap peristiwa memiliki stempel waktu dan membentuk urutan tindakan untuk tiap permintaan layanan. Atribut ini penting untuk memvisualisasikan alur proses, menemukan variasi proses, serta menganalisis frekuensi dan urutan peristiwa. Analis dapat memahami tindakan yang dilakukan dan menemukan jalur umum, hambatan, serta penyimpangan dari prosedur standar.
Mengapa ini penting
Atribut ini menentukan langkah-langkah dalam proses, sehingga peta proses dapat divisualisasikan dan alur serta variasi proses dapat dianalisis.
Sumber data
Diambil dari log audit tiket Zendesk atau aliran peristiwa yang mencatat perubahan dan tindakan.
Contoh
Permintaan layanan dibuatPermintaan ditugaskan kepada agenBalasan publik pertama dari agen dikirimPermintaan layanan diselesaikan
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Stempel waktu saat data terakhir kali diperbarui atau diekstrak dari sistem sumber. | ||
|
Deskripsi
Atribut ini menunjukkan waktu terakhir dataset diperbarui dari Zendesk Support. Informasi ini memberi konteks tentang kebaruan data yang sedang dianalisis. Dengan mengetahui waktu pembaruan terakhir, analis dan pengguna bisnis dapat memastikan apakah informasi proses yang dilihat sudah terbaru. Informasi ini membantu mengelola ekspektasi tentang kebaruan data dan penting untuk pelaporan serta pemantauan.
Mengapa ini penting
Menunjukkan seberapa baru data yang digunakan, sehingga pengguna memahami kemutakhiran analisis proses.
Sumber data
Kolom metadata ini dibuat dan disimpan saat ekstraksi data untuk mencatat stempel waktu proses ekstraksi.
Contoh
2023-10-27T02:00:00Z
|
|||
|
Sistem sumber
SourceSystem
|
Sistem pencatatan utama tempat data diambil. | ||
|
Deskripsi
Atribut ini menunjukkan sistem asal data permintaan layanan, dalam hal ini Zendesk Support. Informasi ini membantu tata kelola dan pelacakan asal-usul data, terutama saat data dari beberapa sistem digabungkan. Dalam analisis, atribut ini memastikan data dikaitkan dengan sumber yang benar. Hal ini penting untuk menjaga integritas data dan memahami konteks proses, khususnya di lingkungan yang menggunakan beberapa sistem.
Mengapa ini penting
Menunjukkan asal data. Informasi ini penting untuk tata kelola data dan membedakan data proses di lingkungan yang terintegrasi.
Sumber data
Nilai tetap ini ditambahkan saat ekstraksi data untuk menandai asal data.
Contoh
Zendesk Support
|
|||
|
Agen yang ditugaskan
AssignedAgent
|
Nama atau ID agen layanan pelanggan yang ditugaskan untuk menangani permintaan layanan. | ||
|
Deskripsi
Atribut ini menunjukkan agen yang bertanggung jawab atas suatu aktivitas atau permintaan layanan pada waktu tertentu. Agen dapat berubah selama siklus permintaan jika tugas dialihkan. Analisis berdasarkan agen yang ditugaskan membantu memahami beban kerja, kinerja, dan efisiensi agen. Atribut ini mendukung dashboard 'Beban kerja dan efisiensi agen' dengan membandingkan waktu penanganan dan volume kasus antaragen. Hasilnya dapat membantu menemukan kebutuhan pendampingan dan menyeimbangkan beban kerja.
Mengapa ini penting
Mencatat agen yang melakukan tindakan, sehingga kinerja individu, distribusi beban kerja, dan alokasi sumber daya dapat dianalisis.
Sumber data
Zendesk Tickets API, kolom
Contoh
John SmithJane DoeSupportBot
|
|||
|
Apakah SLA terlampaui
IsSlaBreached
|
Penanda boolean yang menunjukkan apakah waktu penyelesaian permintaan layanan melampaui target SLA. | ||
|
Deskripsi
Atribut hasil perhitungan ini berupa penanda benar atau salah yang menunjukkan apakah permintaan layanan memenuhi target waktu penyelesaian dalam Service Level Agreement. Nilainya diperoleh dengan membandingkan durasi penyelesaian aktual dengan target SLA. Penanda ini memudahkan analisis kepatuhan terhadap SLA. Data ini menjadi dasar bagi dasbor “Kinerja kepatuhan SLA” dan KPI “Tingkat kepatuhan SLA”. Anda dapat dengan cepat merangkum dan melihat jumlah permintaan yang memenuhi target layanan dibandingkan dengan yang tidak.
Mengapa ini penting
Memberikan hasil yang jelas, ya atau tidak, untuk kinerja SLA setiap kasus sehingga pemantauan dan pelaporan kepatuhan lebih mudah.
Sumber data
Dihitung saat transformasi data dengan membandingkan total waktu penyelesaian dengan SlaTargetResolutionTime.
Contoh
truefalse
|
|||
|
Jenis permintaan layanan
ServiceRequestType
|
Klasifikasi permintaan layanan, seperti 'Pertanyaan', 'Insiden', 'Masalah', atau 'Tugas'. | ||
|
Deskripsi
Atribut ini mengelompokkan permintaan layanan berdasarkan jenisnya. Klasifikasi biasanya ditetapkan saat permintaan dibuat atau ditriase, lalu digunakan untuk menentukan alur kerja dan prioritas yang sesuai. Dalam analisis, pengelompokan berdasarkan jenis permintaan layanan sangat penting. Anda dapat membandingkan waktu penyelesaian, tingkat eskalasi, dan alur proses untuk berbagai jenis masalah, seperti yang ditampilkan di dashboard 'Analisis waktu penyelesaian permintaan layanan' dan 'Tingkat dan penyebab eskalasi internal'. Analisis ini membantu menemukan jenis permintaan yang lebih sulit atau kurang efisien untuk ditangani.
Mengapa ini penting
Mengelompokkan permintaan agar kinerja berbagai jenis masalah dapat dibandingkan dan dianalisis. Hal ini penting untuk menentukan perbaikan proses yang tepat sasaran.
Sumber data
Zendesk Tickets API, kolom
Contoh
PertanyaanInsidenMasalahTugas
|
|||
|
Prioritas
Priority
|
Tingkat prioritas yang ditetapkan untuk permintaan layanan, seperti 'Rendah', 'Normal', 'Tinggi', atau 'Mendesak'. | ||
|
Deskripsi
Prioritas menunjukkan tingkat urgensi permintaan layanan dan sering memengaruhi posisinya dalam antrean serta target waktu penyelesaian. Dengan informasi ini, agen dapat menangani masalah paling penting terlebih dahulu. Atribut ini penting untuk analisis kinerja dan SLA. Dashboard 'Analisis waktu penyelesaian permintaan layanan' menggunakan prioritas untuk mengelompokkan data. Anda dapat melihat apakah permintaan berprioritas tinggi ditangani lebih cepat daripada permintaan berprioritas rendah, serta apakah sumber daya dialokasikan sesuai kebutuhan bisnis.
Mengapa ini penting
Menunjukkan tingkat urgensi permintaan. Informasi ini penting untuk menganalisis kepatuhan terhadap SLA dan memastikan masalah mendesak segera ditangani.
Sumber data
Zendesk Tickets API, field
Contoh
RendahNormalTinggiMendesak
|
|||
|
Saluran komunikasi
CommunicationChannel
|
Saluran yang digunakan untuk mengirim permintaan layanan atau berkomunikasi. | ||
|
Deskripsi
Atribut ini menunjukkan cara komunikasi yang digunakan, seperti email, formulir web, chat, atau telepon. Informasi ini mencerminkan cara pelanggan berinteraksi dengan tim layanan. Memahami penggunaan tiap saluran penting untuk merencanakan sumber daya dan meningkatkan pengalaman pelanggan. Dasbor “Ringkasan penggunaan saluran komunikasi” menganalisis data ini untuk mengetahui saluran yang paling banyak digunakan dan apakah saluran tertentu berkaitan dengan waktu penyelesaian yang lebih lama atau alur proses yang berbeda. Hasilnya dapat membantu menentukan saluran yang perlu ditingkatkan atau diotomatisasi.
Mengapa ini penting
Menunjukkan cara pelanggan dan agen berinteraksi, sehingga Anda dapat menganalisis efisiensi tiap saluran serta dampaknya terhadap proses dan pengalaman pelanggan.
Sumber data
Zendesk Tickets API, field
Contoh
webemailapichat
|
|||
|
Target waktu penyelesaian SLA
SlaTargetResolutionTime
|
Batas waktu yang ditetapkan untuk menyelesaikan permintaan layanan berdasarkan kebijakan SLA. | ||
|
Deskripsi
Atribut ini menetapkan target Service Level Agreement (SLA) untuk menyelesaikan tiket. Targetnya sering berubah sesuai faktor seperti prioritas dan jenis permintaan, atau paket layanan pelanggan. Atribut ini menjadi dasar bagi dasbor “Kinerja kepatuhan SLA”. Waktu penyelesaian aktual dibandingkan dengan target ini. Analisis hasilnya membantu mengukur kualitas layanan dan memastikan kewajiban kontraktual kepada pelanggan terpenuhi.
Mengapa ini penting
Menetapkan komitmen layanan kepada pelanggan dan menjadi tolok ukur untuk mengukur ketepatan waktu serta kepatuhan terhadap SLA.
Sumber data
Diambil dari kebijakan SLA yang berlaku untuk tiket. Informasi ini tersedia melalui Zendesk Ticket Metrics API.
Contoh
144002880086400
|
|||
|
Apakah dibuka kembali
IsReopened
|
Penanda boolean yang menunjukkan apakah permintaan layanan dibuka kembali setelah ditandai selesai. | ||
|
Deskripsi
Atribut ini bernilai benar jika status permintaan layanan kembali menjadi terbuka setelah sebelumnya ditandai selesai atau ditutup. Ini menandakan bahwa penyelesaian awal belum memadai. Penanda ini penting untuk melacak pengerjaan ulang dan kegagalan penyelesaian pada kontak pertama. Data ini mendukung dasbor “Tren permintaan layanan yang dibuka kembali” dan KPI “Tingkat permintaan layanan dibuka kembali”. Anda dapat dengan mudah menghitung dan menganalisis kasus yang memerlukan perhatian tambahan, yang sering kali menunjukkan adanya masalah mendasar.
Mengapa ini penting
Menandai pengerjaan ulang dan penyelesaian yang gagal, sehingga Anda dapat mengukur kualitas dan efektivitas solusi yang diberikan.
Sumber data
Dihitung saat transformasi data dengan memeriksa apakah status tiket berubah dari “resolved” atau “closed” kembali menjadi “open”.
Contoh
truefalse
|
|||
|
Grup agen
AgentGroup
|
Grup atau tim dukungan yang menangani permintaan layanan. | ||
|
Deskripsi
Atribut ini menunjukkan tim agen yang bertanggung jawab atas permintaan layanan. Permintaan biasanya diarahkan ke grup tertentu berdasarkan keahlian, area produk, atau bahasa. Analisis berdasarkan grup agen membantu Anda memahami kinerja tim, pembagian beban kerja, dan pola eskalasi antartim. Tampilan ini memberi gambaran yang lebih luas daripada analisis per agen dan dapat membantu menemukan masalah sistemik di departemen atau fungsi tertentu.
Mengapa ini penting
Mencatat tim yang bertanggung jawab, sehingga Anda dapat menganalisis kinerja grup, serah terima antartim, dan alokasi sumber daya di berbagai tingkat atau bidang dukungan.
Sumber data
Zendesk Tickets API, field
Contoh
Dukungan tingkat 1Dukungan teknisPenagihan
|
|||
|
Jumlah permintaan informasi
InformationRequestCount
|
Jumlah permintaan informasi yang diajukan kepada pelanggan untuk satu permintaan layanan. | ||
|
Deskripsi
Metrik hasil perhitungan ini menghitung berapa kali aktivitas “Informasi diminta dari pelanggan” terjadi untuk setiap permintaan layanan. Jumlah yang tinggi menunjukkan bahwa agen mungkin belum mengumpulkan semua informasi yang diperlukan sejak awal. Atribut ini digunakan pada dasbor “Analisis permintaan informasi berulang”. Dengan melacak jumlahnya, Anda dapat menemukan proses yang kurang efisien dan kebutuhan pelatihan agen. Mengurangi permintaan informasi berulang dapat memangkas waktu penyelesaian dan meningkatkan pengalaman pelanggan.
Mengapa ini penting
Mengukur komunikasi bolak-balik dengan pelanggan dan menyoroti proses yang kurang efisien, yang memperpanjang waktu penyelesaian serta menurunkan kualitas pengalaman pelanggan.
Sumber data
Dihitung dengan menghitung jumlah peristiwa yang memiliki ActivityName 'Information Requested From Customer' untuk setiap Service Request.
Contoh
013
|
|||
|
Kategori produk atau layanan
ProductServiceCategory
|
Produk, layanan, atau fitur tertentu yang menjadi pokok permintaan pelanggan. | ||
|
Deskripsi
Atribut ini memberi konteks terperinci dengan mengelompokkan permintaan layanan berdasarkan produk atau area layanan. Agen sering mengisinya secara manual, atau sistem mengisinya berdasarkan isi permintaan. Pengelompokan ini penting untuk dasbor “Akurasi kategorisasi permintaan” dan “Rincian waktu siklus investigasi”. Anda dapat menganalisis produk yang paling banyak memicu permintaan dukungan, produk yang paling sulit ditangani, serta kesesuaian antara kategori awal dan solusi akhir. Hasilnya dapat membantu memperbaiki perutean permintaan dan pelatihan agen.
Mengapa ini penting
Menghubungkan permintaan dengan area bisnis, produk, atau layanan tertentu. Dengan begitu, Anda dapat menganalisis area yang bermasalah dan dampaknya terhadap proses.
Sumber data
Biasanya berupa field tiket khusus di Zendesk. Nama field yang tepat bergantung pada konfigurasi Zendesk Anda.
Contoh
Aplikasi selulerPengelolaan langgananIntegrasi APIPerangkat keras
|
|||
|
Kode penyelesaian
ResolutionCode
|
Kode atau kategori yang menunjukkan alasan permintaan akhirnya diselesaikan atau ditutup. | ||
|
Deskripsi
Kode penyelesaian memberikan informasi terstruktur tentang hasil permintaan layanan. Contohnya antara lain “Diselesaikan oleh agen”, “Duplikat”, “Tidak perlu tindakan”, atau “Masalah yang diketahui”. Kode ini memberi konteks lebih jelas daripada status “Ditutup” saja. Atribut ini sangat berguna untuk analisis akar masalah. Pada dasbor “Tren permintaan layanan yang dibuka kembali”, analisis tingkat pembukaan kembali berdasarkan kode penyelesaian dapat menunjukkan apakah solusi tertentu kurang efektif sehingga pelanggan kembali menghubungi tim dukungan.
Mengapa ini penting
Memberi gambaran tentang hasil permintaan layanan. Informasi ini penting untuk menganalisis akar masalah dan memahami alasan permintaan dibuka kembali.
Sumber data
Biasanya berupa field tiket khusus di Zendesk. Nama field yang tepat bergantung pada konfigurasi Zendesk Anda.
Contoh
Selesai pada kontak pertamaDieskalasikan ke tingkat 2Menunggu pelangganBug produk
|
|||
|
Penilaian kepuasan
SatisfactionRating
|
Skor kepuasan yang diberikan pelanggan setelah permintaan layanan diselesaikan. | ||
|
Deskripsi
Atribut ini mencatat masukan pelanggan tentang pengalaman layanan mereka. Biasanya, masukan dikumpulkan melalui survei setelah tiket diselesaikan. Penilaian umum mencakup “Baik”, “Buruk”, atau skor angka. Atribut ini mengukur sentimen pelanggan secara langsung dan menjadi metrik hasil yang penting. Data ini digunakan untuk menghitung KPI “Skor sentimen pelanggan”. Dengan menganalisis penilaian kepuasan bersama data proses, seperti waktu penyelesaian atau jumlah interaksi dengan agen, Anda dapat mengetahui perilaku proses yang menghasilkan pengalaman pelanggan lebih baik.
Mengapa ini penting
Mengukur langsung masukan pelanggan tentang layanan yang diberikan dan menghubungkan kinerja proses dengan hasil bagi pelanggan.
Sumber data
Zendesk Tickets API, field
Contoh
baikburukditawarkan
|
|||
|
Waktu selesai
EndTime
|
Stempel waktu yang menunjukkan kapan suatu aktivitas atau peristiwa selesai. | ||
|
Deskripsi
Waktu selesai menunjukkan kapan suatu aktivitas berakhir. Dalam banyak struktur log peristiwa, waktu mulai aktivitas berikutnya dapat digunakan sebagai waktu selesai aktivitas saat ini. Untuk aktivitas berbasis status seperti 'Agen menyelidiki masalah', waktu ini menandai berakhirnya status tersebut. Atribut ini penting untuk menghitung durasi aktivitas secara tepat, yang menjadi bagian utama analisis kinerja. Data ini membantu menemukan langkah yang paling banyak memakan waktu dan menjadi dasar analisis hambatan serta perhitungan efisiensi sumber daya secara terperinci.
Mengapa ini penting
Memungkinkan penghitungan durasi aktivitas, yang penting untuk menemukan hambatan dan mengukur kinerja.
Sumber data
Nilai ini sering diperoleh dengan menggunakan StartTime peristiwa berikutnya dalam urutan untuk permintaan layanan yang sama.
Contoh
2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
|
|||
Aktivitas layanan pelanggan
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Informasi diminta dari pelanggan
|
Aktivitas ini terjadi saat agen memerlukan informasi tambahan dari pelanggan untuk melanjutkan penanganan, lalu mengubah status tiket menjadi 'pending'. Perubahan status ini secara langsung menunjukkan bahwa proses sedang menunggu pihak eksternal. | ||
|
Mengapa ini penting
Aktivitas ini menunjukkan adanya ketergantungan pada pelanggan dan menghentikan sementara penghitungan SLA internal. Jika terjadi berulang kali pada satu tiket, hal ini dapat menandakan pengumpulan informasi awal yang kurang lengkap dan memperpanjang waktu penyelesaian.
Sumber data
Perubahan status ini tercatat secara langsung di Zendesk Ticket Audits API. Peristiwa ini direkam saat kolom 'status' berubah menjadi 'pending'.
Pengumpulan data
Temukan peristiwa 'Change' di Ticket Audits saat status tiket diubah menjadi 'pending'.
Jenis peristiwa
explicit
|
|||
|
Permintaan ditugaskan kepada agen
|
Peristiwa ini menandakan bahwa permintaan layanan telah ditugaskan kepada agen tertentu untuk ditangani. Penugasan dapat dilakukan otomatis berdasarkan aturan perutean atau secara manual oleh ketua tim maupun agen. | ||
|
Mengapa ini penting
Penugasan merupakan tahap penting untuk memastikan akuntabilitas dan mengelola beban kerja. Analisis waktu penugasan dan pola penugasan ulang dapat mengungkap hambatan dalam proses triase dan distribusi.
Sumber data
Peristiwa 'Change' ini tercatat secara langsung di Zendesk Ticket Audits API setiap kali kolom 'assignee_id' diisi atau diubah.
Pengumpulan data
Lacak perubahan pada kolom 'assignee_id' di log Ticket Audits.
Jenis peristiwa
explicit
|
|||
|
Permintaan layanan dibuat
|
Aktivitas ini menandai awal proses layanan pelanggan, saat tiket baru dibuat di Zendesk melalui saluran seperti email, formulir web, atau chat. Sistem mencatat peristiwa ini secara langsung dengan ID tiket unik dan stempel waktu saat tiket dibuat. | ||
|
Mengapa ini penting
Sebagai peristiwa awal utama, aktivitas ini penting untuk menghitung durasi keseluruhan kasus dan menganalisis volume permintaan yang masuk dari waktu ke waktu. Aktivitas ini menjadi dasar untuk mengukur KPI seperti waktu hingga respons pertama dan total waktu penyelesaian.
Sumber data
Peristiwa ini tercatat secara langsung di Zendesk Ticket Audits API. Peristiwa ini sesuai dengan peristiwa 'Create' pada tiket dan mencatat stempel waktu awal pembuatannya.
Pengumpulan data
Diambil dari peristiwa pembuatan tiket dalam log Ticket Audits.
Jenis peristiwa
explicit
|
|||
|
Permintaan layanan dibuka kembali
|
Aktivitas ini terjadi jika pelanggan membalas tiket dengan status 'solved'. Zendesk otomatis mengubah statusnya kembali menjadi 'open', yang menandakan masalah belum sepenuhnya terselesaikan. | ||
|
Mengapa ini penting
Tiket yang dibuka kembali merupakan indikator penting kegagalan penyelesaian pada kontak pertama dan rendahnya kualitas solusi. Analisis frekuensi dan alasan tiket dibuka kembali membantu menemukan hal yang perlu diperbaiki dalam pelatihan agen dan prosedur penyelesaian.
Sumber data
Perubahan status ini tercatat secara langsung di Ticket Audits API saat status berubah dari 'solved' kembali menjadi 'open'.
Pengumpulan data
Lacak peristiwa 'Change' status dari 'solved' menjadi 'open'.
Jenis peristiwa
explicit
|
|||
|
Permintaan layanan diselesaikan
|
Agen menandai permintaan layanan sebagai 'solved' setelah memberikan solusi kepada pelanggan. Status ini bersifat sementara karena pelanggan masih dapat membalas dan membuka kembali tiket sebelum tiket ditutup secara permanen. | ||
|
Mengapa ini penting
Ini merupakan tahap utama untuk mengukur waktu penyelesaian dan efisiensi agen. Tahap ini menandai saat agen menganggap pekerjaan selesai dan menjadi dasar untuk menganalisis pekerjaan ulang jika tiket dibuka kembali.
Sumber data
Perubahan status ini tercatat secara langsung di Zendesk Ticket Audits API saat kolom 'status' diubah menjadi 'solved'.
Pengumpulan data
Temukan peristiwa 'Change' di Ticket Audits saat status tiket diubah menjadi 'solved'.
Jenis peristiwa
explicit
|
|||
|
Permintaan layanan ditutup
|
Ini adalah aktivitas terakhir yang menandai penutupan permanen permintaan layanan. Biasanya, tiket ditutup secara otomatis setelah jangka waktu tertentu sejak ditandai sebagai 'solved', jika pelanggan tidak mengirim balasan baru. | ||
|
Mengapa ini penting
Sebagai peristiwa akhir yang definitif, aktivitas ini mengakhiri siklus tiket. Jeda antara status 'solved' dan 'closed' merupakan periode ketika tiket masih dapat dibuka kembali. Peristiwa 'closed' mengonfirmasi bahwa penyelesaian telah diterima.
Sumber data
Perubahan status ini tercatat secara langsung di Zendesk Ticket Audits API saat kolom 'status' diubah menjadi 'closed'.
Pengumpulan data
Temukan peristiwa 'Change' di Ticket Audits saat status tiket diubah menjadi 'closed'.
Jenis peristiwa
explicit
|
|||
|
Balasan publik pertama dari agen dikirim
|
Aktivitas ini menandai saat pertama kali agen mengirim komentar publik kepada pelanggan, bukan sekadar konfirmasi otomatis. Peristiwa ini menjadi indikator penting keterlibatan awal agen dalam menangani masalah pelanggan. | ||
|
Mengapa ini penting
Tahap ini penting untuk mengukur SLA 'First Reply Time', indikator utama kecepatan layanan. Tahap ini membedakan komunikasi otomatis dari dimulainya investigasi dan dukungan aktif oleh agen.
Sumber data
Temukan komentar publik pertama dalam aliran Ticket Comments yang ditulis oleh agen manusia, bukan pengguna sistem otomatis.
Pengumpulan data
Periksa komentar tiket, saring komentar publik dari agen, lalu pilih komentar dengan stempel waktu paling awal.
Jenis peristiwa
inferred
|
|||
|
Eskalasi internal dipicu
|
Aktivitas ini menunjukkan pemindahan permintaan layanan ke tim internal lain atau tingkat dukungan yang lebih tinggi. Biasanya, aktivitas ini disimpulkan dari perubahan grup yang ditugaskan pada tiket. | ||
|
Mengapa ini penting
Melacak eskalasi penting untuk menemukan kelemahan proses, kesenjangan pengetahuan pada tim dukungan lini pertama, dan jenis permintaan yang rumit. Tingkat eskalasi yang tinggi dapat menandakan perlunya pelatihan atau dokumentasi proses yang lebih baik.
Sumber data
Disimpulkan dari peristiwa 'Change' di Ticket Audits API saat kolom 'group_id' diubah. Perubahan grup menandakan serah terima antar tim.
Pengumpulan data
Pantau perubahan pada kolom 'group_id' di log Ticket Audits.
Jenis peristiwa
inferred
|
|||
|
Pelanggan merespons
|
Peristiwa ini terjadi saat pelanggan membalas tiket, biasanya ketika statusnya 'pending'. Zendesk otomatis mengubah status tiket dari 'pending' kembali menjadi 'open', yang menandakan agen dapat melanjutkan pekerjaan. | ||
|
Mengapa ini penting
Aktivitas ini menandai berakhirnya waktu tunggu dan menjadi pemicu untuk melanjutkan proses. Analisis waktu yang dibutuhkan pelanggan untuk merespons dapat memberi gambaran tentang kejelasan permintaan agen.
Sumber data
Peristiwa ini sesuai dengan komentar publik baru dari pengguna akhir, yang memicu perubahan status langsung dari 'pending' menjadi 'open' di Ticket Audits API.
Pengumpulan data
Lacak peristiwa 'Change' status dari 'pending' menjadi 'open', atau temukan komentar publik baru dari pengguna akhir.
Jenis peristiwa
explicit
|
|||
|
Penilaian kepuasan diterima
|
Peristiwa ini terjadi saat pelanggan mengirimkan jawaban survei kepuasan, berupa penilaian seperti 'Good' atau 'Bad'. Penilaian dan komentar terkait dicatat pada tiket. | ||
|
Mengapa ini penting
Umpan balik langsung dari pelanggan sangat berharga untuk mengukur kualitas layanan dan persepsi pelanggan. Dengan menganalisis penilaian dalam konteks alur proses, Anda dapat melihat kaitan antara aktivitas atau agen tertentu dengan hasil yang diperoleh.
Sumber data
Dicatat sebagai peristiwa 'Change' di Ticket Audits API saat kolom 'satisfaction_rating' diisi dengan skor dan komentar pelanggan.
Pengumpulan data
Saring log Ticket Audit untuk menemukan perubahan pada kolom 'satisfaction_rating'.
Jenis peristiwa
explicit
|
|||
|
Permintaan dikategorikan dan diprioritaskan
|
Aktivitas ini terjadi saat agen atau otomatisasi menetapkan atau memperbarui kolom tiket, seperti jenis, kategori, dan prioritas. Langkah ini tercatat sebagai peristiwa perubahan dalam riwayat tiket. | ||
|
Mengapa ini penting
Kategorisasi dan penentuan prioritas yang tepat penting untuk mengarahkan permintaan dan mengalokasikan sumber daya secara efisien. Analisis aktivitas ini membantu menilai ketepatan triase awal dan dampaknya terhadap waktu penyelesaian.
Sumber data
Diambil dari Zendesk Ticket Audits API sebagai peristiwa 'Change'. Peristiwa ini dapat dikenali dari pembaruan pertama pada kolom seperti 'priority', 'type', atau kolom khusus terkait kategorisasi.
Pengumpulan data
Saring log Ticket Audit untuk menemukan peristiwa 'Change' pertama pada kolom kategorisasi utama setelah tiket dibuat.
Jenis peristiwa
explicit
|
|||
|
Respons awal dikirim
|
Aktivitas ini menunjukkan respons pertama otomatis yang dikirim kepada pelanggan untuk mengonfirmasi bahwa permintaan mereka telah diterima. Biasanya, Zendesk trigger mengirim notifikasi email dengan templat segera setelah tiket dibuat. | ||
|
Mengapa ini penting
Melacak aktivitas ini penting untuk mengukur kecepatan respons awal dan mengelola ekspektasi pelanggan. Waktu antara pembuatan permintaan dan pengiriman konfirmasi menjadi metrik penting bagi kepuasan pelanggan.
Sumber data
Disimpulkan dari komentar publik pertama pada tiket jika penulisnya adalah pengguna otomatis atau komentar dibuat beberapa detik setelah tiket dibuat. Hal ini dapat diketahui dengan menganalisis aliran Ticket Comments.
Pengumpulan data
Temukan komentar publik pertama yang dibuat oleh otomatisasi atau trigger segera setelah tiket dibuat.
Jenis peristiwa
inferred
|
|||
|
SLA dilanggar
|
Aktivitas ini menandai waktu ketika permintaan layanan tidak memenuhi Service Level Agreement yang telah ditetapkan, seperti target waktu respons pertama atau waktu penyelesaian. Peristiwa ini dihitung dengan membandingkan stempel waktu aktivitas tiket dengan kebijakan SLA. | ||
|
Mengapa ini penting
Pelanggaran SLA berdampak langsung pada kepuasan pelanggan dan kepatuhan terhadap kontrak. Menganalisis waktu dan penyebabnya penting untuk menemukan keterlambatan sistemis, kekurangan sumber daya, atau target kinerja yang tidak realistis.
Sumber data
Data ini dapat diambil dari Zendesk Ticket Metrics API, yang menyimpan stempel waktu pelanggaran SLA ('breached_at'). Anda juga dapat menghitungnya dengan membandingkan stempel waktu peristiwa tiket dengan aturan SLA yang ditetapkan.
Pengumpulan data
Gunakan stempel waktu 'breached_at' dari Ticket Metrics API, atau hitung dengan membandingkan waktu penyelesaian dengan batas waktu dalam kebijakan SLA.
Jenis peristiwa
calculated
|
|||
|
Survei kepuasan dikirim
|
Aktivitas ini menandai saat survei kepuasan pelanggan (CSAT) dikirim secara otomatis kepada pelanggan. Biasanya, survei dikirim tidak lama setelah tiket ditandai sebagai 'solved'. | ||
|
Mengapa ini penting
Aktivitas ini memulai proses pengumpulan umpan balik pelanggan. Mengetahui kapan dan apakah survei dikirim penting untuk memahami skor kepuasan dan mengukur efektivitas program umpan balik.
Sumber data
Aktivitas ini dapat disimpulkan dari log otomatisasi atau penambahan tag tertentu pada tiket. Bagian 'satisfaction_rating' di Ticket Audits API juga mencatat waktu survei ditawarkan.
Pengumpulan data
Cari tag seperti 'csat_sent' atau gunakan stempel waktu saat survei penilaian kepuasan ditawarkan.
Jenis peristiwa
inferred
|
|||
Panduan ekstraksi data
Siap memulai?
Mulai tingkatkan layanan pelanggan Anda dengan menyiapkan data menggunakan templat ini. Temukan wawasan penting dan tingkatkan efisiensi operasional Zendesk Support.
Atasi Hambatan Layanan Pelanggan dan Tingkatkan CSAT
Kurangi kontak berulang. Capai FCR 80% dan tingkatkan kepuasan pelanggan.
Tidak perlu kartu kredit