Cara Membuat Laporan Tiket Dukungan: Langkah demi Langkah

Laporan tiket dukungan sebagian besar merupakan masalah definisi. Tiket yang dibuat, tiket yang diselesaikan, waktu balasan pertama, dan waktu penyelesaian semuanya terdengar jelas dengan sendirinya. Namun, masing-masing memiliki lebih dari satu arti resmi di dalam help desk yang sama.

Tetapkan aturan penghitungan dan laporan akan tersusun dengan sendirinya. Lewatkan langkah tersebut, maka dua orang yang jujur akan menarik data ekspor yang sama tetapi menghasilkan selisih waktu hingga berjam-jam.

Panduan ini membahas apa saja yang perlu dimasukkan ke dalam laporan, empat poin di mana definisi bisa berbeda, dan cara menyusunnya dari ekspor tiket.

Apa saja yang perlu ada dalam laporan tiket dukungan

Volume saja hampir tidak memberi tahu Anda apa-apa. Susunannya lah yang membuat angka-angka tersebut aman untuk dibaca.

Elemen	Mengapa ini ada di sana
Tiket yang dibuat dalam periode tersebut	Sisi permintaan
Tiket yang diselesaikan dalam periode tersebut	Sisi penawaran, berdasarkan aturan status yang ditetapkan
Backlog di akhir periode	Semua yang belum diselesaikan atau ditutup
Waktu balasan pertama	Berdasarkan jam kerja yang ditetapkan dan definisi yang ditentukan
Waktu penyelesaian	Pertama atau penuh, disebutkan secara eksplisit
Tiket yang dibuka kembali	Sinyal kualitas yang disembunyikan oleh angka-angka lainnya
Tiket yang tidak dibalas	Di mana proses gagal sepenuhnya
Dasar tanggal dan cakupan yang ditetapkan	Saluran, merek, dan antrean mana saja yang disertakan

Dua baris memiliki bobot yang lebih besar daripada yang terlihat. Tiket yang dibuka kembali dan tidak dibalas adalah poin di mana laporan berhenti menjadi sekadar papan skor dan mulai menjadi berguna.

Zendesk mempublikasikan formula dasarnya, yang membuat definisi-definisi tersebut dapat diverifikasi dan bukan sekadar masalah opini. Referensi metrik dan atribut miliknya menyediakan masing-masing formula tersebut.

Mulailah dengan yang paling sederhana. Tiket yang diselesaikan adalah "jumlah tiket yang diselesaikan atau ditutup," sehingga metrik ini mencakup dua status, bukan hanya satu.

"Waktu balasan pertama" memiliki dua definisi resmi

Ini adalah percabangan yang paling sering menimbulkan ketidaksepakatan, dan vendor memperingatkannya secara langsung.

Zendesk's SLA documentation menyatakannya dalam satu baris: "Jangan bingung membedakan waktu balasan SLA dengan metrik waktu balasan bawaan Zendesk."

Metrik bawaan sangat ketat tentang siapa yang membalas. Zendesk menyatakan bahwa "waktu balasan pertama dihitung secara eksklusif berdasarkan balasan agen." Tindakan otomatis dan yang terkait dengan bot "tidak dipertimbangkan saat menghitung waktu balasan pertama."

Metrik SLA tidak demikian. Di sana, waktu balasan pertama adalah "waktu antara pembuatan tiket dan komentar publik pertama dari agen (atau balasan otomatis)." Zendesk menambahkan bahwa "metrik waktu balasan terpenuhi jika Anda menyiapkan pemicu untuk membalas otomatis dengan komentar publik."

Jika Anda membaca keduanya bersamaan, konsekuensinya sangat jelas. Balasan otomatis dapat memenuhi target SLA Anda sementara waktu balasan pertama bawaan terus berjalan.

Jadi, laporan yang menunjukkan pencapaian SLA sebesar 98% dan median balasan pertama selama empat jam tidaklah kontradiktif. Laporan tersebut melaporkan dua hal yang berbeda, dan keduanya benar.

Ada dua pengecualian kecil lainnya yang perlu diketahui. Ambil contoh kasus di mana agen membuat tiket dan komentar pertamanya bersifat publik. Referensi metrik durasi menyatakan bahwa stempel waktu kedua "bergeser ke komentar agen publik yang kedua."

Dan tiket yang dibagikan tidak dihitung. Zendesk mencatat bahwa ketika seorang agen berkomentar secara publik dari akun lain menggunakan fitur berbagi tiket, "ini tidak dihitung dalam waktu balasan pertama akun Anda."

"Waktu penyelesaian" juga memiliki dua definisi

Pembagian yang sama juga berlaku pada metrik penyelesaian, dan di sini kedua versi disediakan secara default.

Waktu penyelesaian pertama adalah "durasi antara pembuatan tiket dan penyelesaian pertamanya," yang berakhir pada "saat pertama kali status tiket diatur ke selesai."

Waktu penyelesaian penuh adalah "durasi antara pembuatan tiket dan penyelesaian terbarunya." Ini berakhir pada "saat terakhir kali status tiket diatur ke selesai."

Untuk tiket yang diselesaikan sekali, keduanya identik. Untuk tiket yang diselesaikan, dibuka kembali, dan diselesaikan lagi, keduanya akan berbeda tergantung pada berapa lama putaran kedua berlangsung.

Itulah mengapa tiket yang dibuka kembali harus dimasukkan ke dalam laporan. Zendesk mendefinisikannya sebagai tiket yang "dibuka kembali setelah diselesaikan," dan mencatat bahwa metrik tersebut "tidak mencakup tiket yang diselesaikan dan dibuka kembali selama pembaruan yang sama."

Ada efek tingkat kedua yang sering dilewatkan orang. Rata-rata harian tiket yang diselesaikan hanya menghitungnya "jika saat ini statusnya selesai atau ditutup." Jadi, tiket yang dibuka kembali hari ini secara diam-diam akan keluar dari hitungan tiket yang diselesaikan bulan lalu.

Oleh karena itu, laporan yang Anda jalankan di bulan Juni tidak akan menghasilkan angka yang sama di bulan Agustus. Tidak ada yang rusak; status dasarnya saja yang telah berubah.

Two more metrics separate waiting from working. Waktu tunggu pemohon adalah akumulasi waktu dalam status baru, terbuka, dan ditahan (on-hold), sedangkan waktu tunggu agen adalah akumulasi waktu dalam status tertunda (pending).

Pasangan metrik tersebut menjawab pertanyaan yang tidak bisa dijawab oleh rata-rata penyelesaian. Waktu penyelesaian yang lama karena menunggu pelanggan adalah masalah yang berbeda dari waktu penyelesaian yang lama karena penumpukan antrean.

Jam kalender atau jam kerja

Setiap angka balasan dan penyelesaian dihitung berdasarkan dua jenis jam, dan memilih salah satunya bukanlah pilihan opsional.

Zendesk menyimpan keduanya. Setelah balasan publik pertama, "sistem menghitung waktu balasan pertama dalam jam kalender dan jam kerja." Kedua metrik tersebut "disimpan bersama data tiket."

Tampilan default yang Anda lihat tidaklah netral. Zendesk mencatat bahwa laporan Explore bawaan "menampilkan informasi pada laporan bawaan dalam jam kalender." Metrik jam kerja "tersedia dan dapat digunakan dalam laporan buatan Anda sendiri."

Jadi, tim yang bekerja dari jam sembilan pagi hingga lima sore akan terlihat lambat pada laporan default. Tiket yang masuk pada hari Jumat jam 6 sore akan membawa sekitar 63 jam kalender sebelum Senin pagi, dan hampir nol jam kerja.

Saluran percakapan langsung menambahkan satu kerumitan lagi. Metrik First reply time (sec) untuk perpesanan dan obrolan "mengabaikan pengaturan jam kerja perpesanan dan jam operasional obrolan langsung Anda."

Dan SLA waktu balasan obrolan bersifat opt-in. Zendesk menyatakan bahwa SLA waktu balasan untuk obrolan langsung "dinonaktifkan secara default," sehingga ketiadaannya merupakan masalah konfigurasi dan bukan berarti kinerja yang sempurna.

Cara melakukannya secara manual

Opsi 1: Satu tab per kelompok metrik

Ekspor daftar tiket beserta kolom metriknya, lalu pisahkan volume, waktu balasan, dan waktu penyelesaian ke dalam tab terpisah sebelum membuat ringkasan apa pun.

Letakkan kolom jam kalender dan jam kerja berdampingan daripada memilih salah satunya saat mengekspor. Anda pasti akan ditanyai tentang kolom yang satunya lagi nanti.

Hitung median alih-alih rata-rata (mean) untuk metrik waktu. Beberapa tiket yang dibiarkan terbuka selama hari libur akan menarik rata-rata ke angka yang tidak mencerminkan kondisi tiket yang sebenarnya.

Batasannya adalah spreadsheet tidak dapat melihat riwayat status. Anda hanya mendapatkan status saat ini dari setiap tiket, sehingga perilaku pembukaan kembali harus diambil dari jumlah tiket yang dibuka kembali, bukan dari rekonstruksi riwayat.

Opsi 2: Tab definisi, ditulis terlebih dahulu

Catat definisi waktu balasan, jenis jam yang digunakan, metrik penyelesaian, aturan status untuk tiket selesai, saluran yang masuk dalam cakupan, dan dasar tanggal.

Kemudian catat apa saja yang tidak diklaim oleh laporan tersebut. Menuliskan bahwa pencapaian SLA dan waktu balasan pertama bawaan mengukur hal yang berbeda akan mencegah rekan kerja Anda yang berniat baik mengutipnya sebagai satu angka yang sama.

Batasannya adalah batasan klasik. Mendokumentasikan aturan tidak berarti menerapkannya, dan pada kuartal berikutnya seseorang mungkin akan menyusun ulang tabel pivot hanya berdasarkan ingatan.

Opsi 3: Segmentasikan sebelum merata-ratakan

Pisahkan berdasarkan saluran sebelum menghitung metrik waktu apa pun. Tiket email, obrolan, dan telepon memiliki karakteristik yang berbeda, dan median yang digabungkan tidak akan menggambarkan kondisi saluran mana pun dengan akurat.

Kemudian kecualikan atau tandai tiket yang mendistorsi data. Tiket yang menunggu tanggapan pelanggan selama berminggu-minggu harus ditempatkan di barisnya sendiri, bukan di dalam rata-rata penyelesaian.

Tunjukkan apa saja yang Anda kecualikan dan berapa jumlahnya. Pembaca yang tidak melihat filter tersebut akan menganggap tidak ada penyaringan yang dilakukan.

Batasannya adalah segmentasi melipatgandakan pekerjaan. Tiga saluran dikali dua jenis jam dikali dua metrik penyelesaian menghasilkan dua belas angka yang harus dikelola dengan benar.

Batasan bersama. Ketiganya mengasumsikan bahwa ekspor mencakup satu rentang tanggal dengan dasar tanggal yang sama untuk setiap antrean. Rentang tanggal yang bercampur di berbagai tab adalah kesalahan senyap yang paling sering terjadi dalam laporan ini.

Di mana metode manual mulai melambat

Laporan tiket dukungan pertama mungkin membutuhkan waktu satu sore. Laporan keempat akan memakan waktu lebih lama, karena sistem help desk telah berubah di baliknya.

Saluran baru diaktifkan, sehingga median gabungan bergeser karena alasan yang tidak terkait dengan kinerja. Jam kerja diedit untuk wilayah baru, dan setiap angka jam kerja historis ikut bergeser.

Kemudian efek pembukaan kembali (reopen) muncul. Angka kuartal lalu tidak lagi sama saat ditarik ulang, dan menjelaskan alasannya memakan waktu lebih lama daripada menyusun ulang laporan tersebut.

Ada konsekuensi keempat yang hanya muncul saat berada di bawah tekanan. Seseorang bertanya apakah dukungan menjadi lebih cepat pada kuartal ini. Jawaban yang jujur memerlukan penjelasan tentang jenis jam, definisi, dan kombinasi saluran terlebih dahulu.

Untuk melihat sisi kepuasan dari gambaran yang sama, lihat panduan kami tentang membuat laporan NPS. Jika volume itu sendiri yang menjadi masalah, panduan kami tentang membangun agen AI untuk dukungan pelanggan pra-penjualan membahas tentang sisi pengalihan (deflection).

Cara menyusunnya dengan Powerdrill Bloom

Langkah 1: Unggah ekspor tiket Anda

Unggah ekspor tiket, atau ekspor tiket dan SLA secara bersamaan. Powerdrill Bloom akan menganalisis kolom-kolom tersebut saat diunggah, sehingga stempel waktu yang kosong, format tanggal yang bercampur, dan tiket yang tidak memiliki balasan pertama akan terdeteksi sebelum median dihitung.

Langkah 2: Deskripsikan laporan dalam bahasa sehari-hari

Sebutkan definisinya alih-alih menyusunnya kembali dari awal. Tentukan definisi waktu balasan, jenis jam, metrik penyelesaian mana yang Anda inginkan, aturan status untuk tiket selesai, dan saluran yang masuk dalam cakupan.

Kemudian ajukan pertanyaan yang dapat mendeteksi kesalahan. Tanyakan berapa banyak tiket yang tidak memiliki balasan agen sama sekali. Tanyakan tiket mana saja yang dibuka kembali. Mintalah median per saluran alih-alih satu angka gabungan.

Langkah 3: Ekspor bagan, laporan, atau slide presentasi

Dapatkan tabel metrik per saluran, atau bagan tiket yang dibuat versus diselesaikan dengan backlog di belakangnya. Slide presentasi yang menyertakan definisi di samping angka-angka tersebut dapat dihasilkan dari proses yang sama.

Kesalahan umum

Mengutip pencapaian SLA sebagai waktu balasan pertama. Yang satu menerima balasan otomatis dan yang lainnya mengecualikan tindakan otomatis sepenuhnya.

Membandingkan jam kalender dengan jam kerja. Laporan default memberikan Anda yang pertama, padahal target Anda kemungkinan besar ditetapkan berdasarkan yang kedua.

Menggunakan rata-rata (mean) untuk waktu balasan dan penyelesaian. Beberapa tiket yang terbengkalai akan menggeser rata-rata ke angka yang tidak mencerminkan kondisi tiket riil mana pun.

Menggabungkan saluran. Median untuk obrolan dan email memang berbeda sejak awal, dan menggabungkannya akan menyembunyikan karakteristik keduanya.

Melaporkan waktu penyelesaian tanpa menyebutkan jenisnya. Waktu penyelesaian pertama dan penuh adalah metrik tersimpan yang terpisah, bukan variasi pembulatan.

Menganggap jumlah tiket selesai sebagai angka final. Jumlah tiket selesai hanya mencakup tiket yang saat ini berstatus selesai atau ditutup, sehingga pembukaan kembali tiket akan mengubah data masa lalu.

Mengabaikan tiket yang tidak dibalas. Tiket ini didefinisikan sebagai tiket dengan kurang dari satu balasan agen, dan merupakan indikator kegagalan paling jelas yang dapat ditunjukkan oleh laporan.

Kesimpulan

Tentukan definisi balasan, tentukan jenis jam, pilih penyelesaian pertama atau penuh, tetapkan aturan status, segmentasikan berdasarkan saluran, serta tunjukkan tiket yang dibuka kembali dan tidak dibalas. Hal itu akan menghasilkan laporan tiket dukungan yang dapat ditindaklanjuti.

Apa yang mungkin tidak bisa dilakukan oleh laporan ini adalah membandingkannya secara langsung dengan angka milik perusahaan lain. Definisi-definisi tersebut dapat dikonfigurasi, sehingga tolok ukur yang Anda baca di suatu tempat hampir pasti diukur dengan cara yang berbeda.

Sebaliknya, bandingkan dengan riwayat Anda sendiri berdasarkan seperangkat aturan yang tetap. Versi itulah yang akan memberi tahu Anda apakah ada peningkatan yang nyata.

Jika menyusun ulang laporan ini setiap bulan menyita waktu seharian, coba Powerdrill Bloom pada ekspor tiket Anda. Lihat juga halaman AI report generator dan voice of customer summarizer.

Pertanyaan yang sering diajukan

Mengapa pencapaian SLA saya tidak cocok dengan waktu balasan pertama saya?

Keduanya mengukur peristiwa yang berbeda. Waktu balasan pertama SLA Zendesk dapat dipenuhi oleh balasan otomatis, sedangkan metrik waktu balasan pertama bawaan mengecualikan tindakan otomatis dan bot sepenuhnya.

Haruskah saya melaporkan waktu penyelesaian pertama atau waktu penyelesaian penuh?

Laporkan mana saja yang Anda tentukan. Waktu penyelesaian pertama berakhir pada saat pertama kali tiket diatur ke selesai. Waktu penyelesaian penuh berakhir pada saat terakhir, sehingga tiket yang dibuka kembali membedakan keduanya.

Apakah metrik dukungan diukur dalam jam kalender atau jam kerja?

Keduanya disimpan. Laporan Explore bawaan Zendesk menampilkan jam kalender, dan metrik jam kerja tersedia untuk laporan yang Anda buat sendiri.

Mengapa jumlah tiket selesai pada kuartal lalu berubah?

Jumlah tiket selesai mencakup tiket yang saat ini berstatus selesai atau ditutup. Tiket yang dibuka kembali setelah periode berakhir akan keluar dari hitungan periode tersebut.

Bisakah saya membandingkan waktu penyelesaian saya dengan tolok ukur industri?

Hanya secara garis besar saja. Definisi, jenis jam, dan kombinasi saluran semuanya dapat dikonfigurasi, sehingga angka yang dipublikasikan kemungkinan besar diukur dengan aturan yang berbeda dari milik Anda.