Templat data layanan pelanggan Anda

Zendesk Support
Templat data layanan pelanggan Anda

Templat data layanan pelanggan Anda

Templat ini membantu Anda mengumpulkan data yang tepat untuk menganalisis proses layanan pelanggan. Di dalamnya terdapat atribut data penting yang perlu dikumpulkan, aktivitas utama yang perlu dilacak, serta panduan praktis untuk mengekstrak informasi tersebut. Gunakan panduan ini untuk menyusun log peristiwa yang dapat membantu Anda menemukan wawasan dan meningkatkan operasional layanan.
  • Atribut yang disarankan untuk dikumpulkan
  • Aktivitas utama yang perlu dilacak dalam proses layanan pelanggan
  • Panduan ekstraksi data dari Zendesk Support
Baru mengenal log peristiwa? Pelajari cara membuat log peristiwa process mining.

Atribut layanan pelanggan

Berikut field data yang disarankan untuk disertakan dalam log peristiwa agar analisis layanan pelanggan lebih menyeluruh.
5 Wajib 6 Disarankan 7 Opsional
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 id.

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 created_at untuk setiap peristiwa dalam jejak audit.

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 assignee_id. Detail pengguna dapat diambil dari Users API.

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 type.

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 priority.

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 via.channel.

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 group_id. Detail grup dapat diambil dari Groups API.

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 satisfaction_rating.score.

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
Wajib Disarankan Opsional

Aktivitas layanan pelanggan

Berikut langkah proses dan tonggak penting yang perlu dicatat dalam log peristiwa agar proses layanan pelanggan dapat ditemukan dengan akurat.
6 Disarankan 8 Opsional
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
Disarankan Opsional

Panduan ekstraksi data

Cara mengambil data dari Zendesk Support

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.

Mulai uji coba gratis

Tidak perlu kartu kredit