Gunakan template ini
Dukungan hebat dimulai dari dokumentasi tiket yang hebat. Dengan Trupeer, Anda dapat menghemat waktu berjam-jam untuk dokumentasi dukungan dengan memulai dari tiket pelanggan gratis dan template resolusi, menyesuaikannya dengan panduan brand Anda, serta mengubah tiket yang terselesaikan menjadi studi kasus video untuk knowledge base dukungan.
Kebanyakan tim dukungan memiliki sistem tiket yang penuh dengan tiket dan tidak tahu apa yang sebenarnya terjadi. Semuanya dikategorikan sebagai Other, catatan resolusi mengatakan "fixed", dan laporan bulanan hanya menampilkan volume tanpa apa pun lagi.
Itu masalah desain kategori, bukan masalah pelaporan. Template ini mencakup dua bagian tiket: catatan yang Anda tangkap, yang menentukan apa yang bisa Anda pelajari, dan respons yang Anda kirim, yang menentukan pengalaman pelanggan.
Unduh template tiket dan resolusi
Format | Paling cocok untuk |
|---|---|
Excel (.xlsx) | Log tiket, dengan kategori, kode resolusi, dan tab pelaporan |
Word (.docx) | Form tiket, laporan resolusi, dan template respons |
Form tiket yang bisa dicetak dan diisi untuk layanan walk-up atau layanan lapangan | |
Google Sheets | Log bersama untuk tim kecil tanpa alat helpdesk |
Google Docs | Template respons, untuk disalin ke balasan canned helpdesk Anda |
Gratis, bisa diedit, tanpa watermark. Jika Anda sudah memiliki alat helpdesk, gunakan daftar kolom dan redaksi respons serta abaikan log.
Cara menyesuaikan template ini di Trupeer
Langkah 1: Buka Bagian Templates
Buka bagian Templates dari navigasi utama.
Langkah 2: Pilih dan Buka sebuah Template
Klik pada template apa pun yang ingin Anda kerjakan untuk membukanya.
Langkah 3: Perluas Tampilan Template
Jika diperlukan, perluas tampilan template untuk melihat tata letak dan detailnya dengan jelas.
Langkah 4: Edit Template
Klik Edit untuk mulai memodifikasi template yang dipilih.
Di dalam editor, Anda bisa:
Menambahkan bagian baru
Menentukan atau memperbarui aturan pemformatan
Menambahkan logo dan menyesuaikan posisinya serta pengaturan terkait
Langkah 5: Simpan Template yang Anda Sesuaikan
Setelah membuat semua perubahan yang diperlukan, klik Save untuk menyimpan template yang diperbarui sebagai milik Anda.
Langkah 6: Pratinjau dan Penyempurnaan Template
Saat Anda ingin melihat seperti apa tampilan template yang Anda sesuaikan, buka Preview.
Dari layar pratinjau, Anda dapat terus melakukan penyesuaian langsung jika diperlukan, sehingga template tampil persis seperti yang Anda inginkan.
Dengan template tiket pelanggan dan resolusi, Anda bisa:
Menghemat waktu untuk menulis: Lewati halaman kosong dengan struktur yang dibuat untuk dokumentasi tiket.
Standarisasi kualitas dukungan: Kolom bawaan memastikan setiap tiket menangkap informasi penting.
Tetap sesuai brand: Terapkan logo, font, dan warna Anda menggunakan brand kit Trupeer.
Membangun KB yang lebih kuat: Tiket yang terselesaikan menjadi artikel bantuan dan runbook masa depan.
Melihat tren: Tiket yang distandarkan memudahkan untuk mengidentifikasi masalah yang berulang.
Menjangkau tim global: Terjemahkan template tiket ke 65+ bahasa hanya dengan satu klik.
Dua bagian template tiket
Catatan. Yang dicatat: siapa, apa, kapan, seberapa mendesak, kategori mana, apa yang sudah diperbaiki. Bagian ini tidak terlihat oleh pelanggan dan menentukan semuanya yang bisa Anda pelajari nanti.
Respons. Yang diterima pelanggan di setiap tahap: konfirmasi, pembaruan, pemberitahuan eskalasi, resolusi, tindak lanjut. Bagian ini yang akan mereka nilai.
Tim cenderung berinvestasi pada bagian kedua dan mengabaikan bagian pertama, itulah sebabnya pelaporan dukungan sering menghasilkan grafik volume dan tidak memberikan wawasan. Keduanya ada di template ini.
Kolom form tiket
Setiap kolom harus mendapatkan tempatnya. Setiap kolom yang Anda tambahkan memperlambat proses masuk, dan kolom yang tidak pernah digunakan akan terisi sampah.
Dicatat saat masuk
Kolom | Mengapa ada |
|---|---|
Ticket ID | Referensi untuk semua proses berikutnya |
Tanggal dan waktu dibuat | Memulai jam SLA |
Channel | Email, telepon, chat, portal, walk-up. Memberi tahu Anda dari mana permintaan benar-benar masuk |
Nama dan kontak peminta | Siapa yang harus dihubungi |
Akun atau organisasi | Mengelompokkan tiket berdasarkan pelanggan, tempat pola terlihat |
Produk, layanan, atau sistem | Hal yang tidak berfungsi |
Kategori | Lihat di bawah. Kolom paling penting |
Deskripsi | Dalam kata-kata pelanggan, bukan parafrase |
Prioritas | Diturunkan dari dampak dan urgensi, bukan dipilih bebas |
Ditugaskan ke | Satu nama, tidak pernah tim |
Status | Open, in progress, waiting on customer, resolved, closed |
Dicatat saat penutupan
Kolom | Mengapa ada |
|---|---|
Kode resolusi | Apa yang benar-benar memperbaikinya. Lihat di bawah |
Catatan resolusi | Cukup agar orang berikutnya bisa mengulanginya |
Akar masalah | Jika diketahui. Opsional per tiket, penting secara agregat |
Waktu hingga respons pertama | Diukur, bukan diperkirakan |
Waktu hingga resolusi | Tidak termasuk waktu menunggu pelanggan |
Dibuka kembali | Ya atau tidak. Tiket yang dibuka kembali belum terselesaikan |
Artikel pengetahuan dibuat atau diperbarui | Kolom yang memperkuat |
Konfirmasi pelanggan | Apakah mereka setuju bahwa masalah sudah diperbaiki |
Dua kolom terakhir saat masuk dan kolom artikel pengetahuan adalah yang paling sering hilang, dan keduanya adalah yang membuat perbedaan antara antrean dan sistem yang benar-benar meningkatkan.
Kategorisasi yang benar-benar bekerja
Kategori adalah kolom yang menentukan apakah data tiket Anda bernilai, dan hampir selalu rusak.
Dua level, bukan empat. Kategori dan sub-kategori. Hierarki yang lebih dalam menghasilkan penandaan yang tidak konsisten, karena agen berhenti membaca setelah dropdown kedua.
Delapan hingga lima belas kategori tingkat atas. Lebih sedikit dan semuanya menjadi Other. Lebih banyak dan tidak ada yang bisa menemukan yang tepat.
Namai kategori berdasarkan apa yang dialami pelanggan, bukan struktur tim internal Anda. "Tidak bisa login" daripada "Identity platform".
Tidak ada Other. Atau jika Anda harus memilikinya, tinjau setiap bulan dan ubah item berulang menjadi kategori nyata. Bucket Other di atas lima persen berarti taksonomi Anda salah.
Kategorikan saat pertama kali disentuh, dan biarkan agen mengubahnya saat penutupan jika ternyata itu sesuatu yang lain. Kategorisasi retrospektif selalu dilakukan tergesa-gesa dan selalu salah.
Tinjau taksonomi setiap kuartal. Kategori menjadi usang saat produk berubah.
Set awal yang bisa digunakan untuk kebanyakan tim dukungan: akses dan login, penagihan dan pembayaran, penyiapan dan konfigurasi, bagaimana caranya, tidak berfungsi seperti yang diharapkan, masalah data, integrasi, performa, permintaan fitur, bug, perubahan akun, pembatalan.
Kode resolusi
Padanan di sisi penutupan, dan bahkan lebih sering diabaikan. Catatan resolusi yang ditulis sebagai teks bebas tidak bisa dihitung.
Kode | Artinya | Yang diberitahukannya |
|---|---|---|
Fixed by support | Agen menyelesaikannya langsung | Resolusi normal |
Fixed by engineering | Memerlukan perubahan kode atau konfigurasi | Volume cacat produk |
User error or misunderstanding | Produk berfungsi, tetapi ekspektasi tidak sesuai | Kesenjangan dokumentasi atau UX |
Documentation provided | Jawaban sudah ada | Masalah ketercapaian konten, bukan masalah knowledge |
Workaround provided | Masalah mendasar masih ada | Backlog tersembunyi. Perhatikan yang ini |
Duplicate | Masalah yang sama seperti tiket lain | Membuat volume membesar jika tidak dilacak |
No fault found | Tidak bisa direproduksi | Perlu ambang batas sebelum menjadi pola |
Withdrawn by customer | Terselesaikan sendiri atau tidak lagi diperlukan | Sering berarti respons lambat |
Out of scope | Bukan sesuatu yang Anda dukung | Periksa apakah seharusnya |
Dua di antaranya adalah emas diagnostik. Tingginya tingkat dokumentasi yang diberikan berarti konten bantuan Anda ada dan tidak bisa ditemukan. Tingginya tingkat workaround yang diberikan berarti Anda sedang menumpuk masalah yang belum terselesaikan yang akan kembali lagi.
Prioritas, dan cara menetapkannya
Prioritas harus diturunkan, bukan dipilih. Agen yang dibiarkan memilih bebas akan menandai semuanya sebagai tinggi, karena setiap pelanggan merasa urgensinya paling tinggi.
Urgensi rendah | Urgensi sedang | Urgensi tinggi | |
|---|---|---|---|
Dampak rendah | P4 | P4 | P3 |
Dampak sedang | P4 | P3 | P2 |
Dampak tinggi | P3 | P2 | P1 |
Dampak adalah seberapa banyak orang yang terdampak dan seberapa parah. Satu pengguna yang terganggu itu rendah. Satu tim yang terblokir itu tinggi.
Urgensi adalah seberapa cepat harus diselesaikan. Masalah kosmetik itu rendah, terlepas dari berapa banyak orang yang melihatnya. Tenggat waktu yang terblokir itu tinggi.
Publikasikan matriks dan target respons untuk setiap level, sehingga prioritas adalah perhitungan, bukan negosiasi.
Siklus hidup tiket
Tahap | Apa yang terjadi | Apa yang diterima pelanggan |
|---|---|---|
Dibuat | Tiket dibuat, dikategorikan, diprioritaskan | Konfirmasi dengan referensi dan perkiraan waktu |
Ditetapkan | Pemilik ditentukan | Tidak ada apa pun, kecuali pemilik berubah |
Diproses | Sedang dikerjakan | Pembaruan jika melewati waktu yang dijanjikan |
Menunggu pelanggan | Terblokir menunggu informasi | Permintaan yang jelas, plus jendela auto-close yang dinyatakan |
Diekalasi | Diteruskan sesuai matriks | Pemberitahuan siapa yang sekarang memilikinya dan kapan mereka akan merespons |
Terselesaikan | Perbaikan diterapkan, menunggu konfirmasi | Pesan resolusi yang menjelaskan apa yang dilakukan |
Ditutup | Pelanggan mengonfirmasi atau auto-close sudah lewat | Survei kepuasan opsional |
Dibuka kembali | Masalah muncul lagi atau tidak diperbaiki | Konfirmasi bahwa belum terselesaikan |
Status menunggu pelanggan memerlukan jendela auto-close yang ditetapkan, biasanya lima hingga sepuluh hari kerja dengan pengingat sebelum. Tanpa itu, tiket akan tetap terbuka selamanya dan metrik waktu resolusi menjadi tidak berarti.
Template respons berdasarkan tahap
Redaksi yang benar-benar dilihat pelanggan. Pastikan setiap respons singkat, dan ganti placeholder dengan nilai nyata, bukan membiarkannya generik.
Konfirmasi
Terima kasih sudah menghubungi. Referensi Anda adalah [ID] dan saya sedang menelusuri ini sekarang. Saya akan kembali kepada Anda pada [time] dengan pembaruan, bahkan jika saya belum punya jawaban lengkap pada saat itu.
Klausul terakhir itu penting. Menjanjikan pembaruan, bukan resolusi, adalah janji yang bisa Anda tepati.
Pembaruan status
Pembaruan singkat untuk [ID]. Saya sudah [what you have done] dan sekarang saya [what is next]. Saya perkirakan ini akan terselesaikan pada [time]. Tidak ada yang perlu Anda lakukan pada tahap ini.
Kirim ini sebelum pelanggan mengejar. Pembaruan tanpa diminta lebih berharga daripada balasan cepat saat pelanggan menagih.
Permintaan informasi
Untuk melanjutkan, saya perlu [specific thing]. Setelah saya memilikinya, saya seharusnya bisa [outcome]. Jika saya tidak mendapat kabar sebelum [date], saya akan menutup tiket, dan Anda bisa membalas kapan saja untuk membukanya kembali.
Minta satu hal saja. Tiga permintaan dalam satu pesan akan menghasilkan satu jawaban.
Pemberitahuan eskalasi
Saya telah mengeskalasi ini ke [name or team] karena [reason]. Mereka akan menghubungi Anda pada [time]. Referensi Anda tetap [ID], dan saya akan tetap disalin.
Sebutkan alasannya. Eskalasi tanpa alasan terdengar seperti masalah yang dilempar-lempar.
Resolusi
Ini sekarang sudah terselesaikan. Penyebabnya adalah [cause] dan saya sudah [what you did]. Anda sekarang seharusnya melihat [expected outcome]. Jika ini terjadi lagi, balas pesan ini dan akan langsung kembali ke saya.
Sebutkan penyebabnya. "Sudah diperbaiki" membuat pelanggan tidak yakin bahwa masalah akan tetap terselesaikan.
Tindak lanjut resolusi
Memeriksa [ID] dari [date]. Apakah semuanya masih berfungsi seperti yang diharapkan? Jika tidak, cukup balas di sini.
Dua hingga tiga hari kemudian, dan hanya untuk hal-hal yang signifikan atau berulang.
Gangguan atau masalah yang meluas
Kami menyadari [issue] yang memengaruhi [scope] dan sedang mengerjakannya sekarang. Saya akan memberi pembaruan kepada Anda pada [time] apa pun perkembangannya. Anda tidak perlu melakukan apa pun.
Proaktif, untuk semua pihak yang terdampak, sebelum mereka menghubungi Anda.
Permintaan maaf setelah kegagalan layanan
Anda benar untuk melaporkan ini dan saya minta maaf. [What went wrong], dan itu adalah tanggung jawab kami. Saya sudah [action taken] dan [what prevents recurrence]. Jika ada hal lain yang masih tertunda, beri tahu saya dan saya akan menanganinya.
Spesifik, tanpa defensif, dan menyatakan apa yang mencegahnya terulang.
Laporan resolusi
Untuk hal-hal yang signifikan, catatan penutupan perlu lebih dari sekadar catatan. Template ini mencakup laporan resolusi yang mencakup:
Referensi tiket dan tanggal. Apa yang dilaporkan pelanggan, dalam kata-kata mereka. Apa yang sebenarnya terjadi, yang sering kali berbeda. Akar masalah. Apa yang dilakukan untuk memperbaikinya. Apakah digunakan workaround dan apakah masalah mendasar masih ada. Waktu hingga respons pertama dan hingga resolusi. Apakah masalah itu muncul lagi. Apa yang diubah untuk mencegah terulang, atau catatan bahwa tidak ada. Artikel pengetahuan dibuat atau diperbarui.
Pasangan terakhir itulah yang mengubah tiket yang terselesaikan menjadi peningkatan. Kebanyakan catatan penutupan berhenti pada apa yang dilakukan, yang hanya membantu orang berikutnya jika mereka menemukan tiket tersebut.
Apa yang memungkinkan data tiket Anda lakukan
Dengan asumsi kolom diisi dengan benar:
Temukan lima kategori teratas berdasarkan volume dan perbaiki yang terbesar. Biasanya yang terbesar adalah masalah dokumentasi atau produk, bukan masalah dukungan.
Bandingkan volume dengan kode resolusi. Volume tinggi dengan kode yang disediakan dokumentasi berarti ketercapaian konten, bukan kapasitas dukungan.
Perhatikan tingkat workaround, yang merupakan backlog tersembunyi Anda.
Cek tingkat dibuka kembali berdasarkan agen dan berdasarkan kategori. Tingginya pembukaan kembali berarti tiket ditutup, bukan diselesaikan.
Lihat campuran channel dari waktu ke waktu. Pertumbuhan telepon sering berarti self-service rusak di suatu tempat.
Silangkan berdasarkan akun. Satu pelanggan yang berulang kali membuat tiket dengan kategori yang sama adalah masalah pelatihan atau konfigurasi, bukan nasib buruk.
Lacak respons pertama dibanding resolusi secara terpisah. Keduanya memiliki penyebab dan perbaikan yang berbeda.
Tidak ada yang mungkin tanpa kategorisasi yang disiplin saat masuk, itulah sebabnya kolom itu mendapat perhatian paling besar dalam template ini.
Help desk, service desk, dan template tiket
Help desk | Service desk | Dukungan pelanggan | |
|---|---|---|---|
Melayani | Staf internal, biasanya TI | Staf internal, katalog layanan yang lebih luas | Pelanggan eksternal |
Fokus | Perbaikan cepat | Permintaan, insiden, perubahan, masalah | Pertanyaan dan masalah produk |
Kerangka | Informal | Sering selaras dengan ITIL | Beragam |
Kolom tambahan | Aset, perangkat | Layanan, referensi perubahan, CI | Akun, langganan, pesanan |
Daftar kolom dan redaksi respons di halaman ini berlaku untuk ketiganya. Service desk yang menjalankan ITIL perlu menambahkan referensi perubahan dan masalah, serta perbedaan antara insiden dan permintaan yang di sana penting dengan cara yang tidak berlaku untuk dukungan pelanggan.
Cara menyiapkannya
Rancang kategori terlebih dahulu, bersama orang-orang yang akan menggunakannya. Delapan hingga lima belas, dua level, dinamai berdasarkan apa yang dialami pelanggan.
Tentukan kolom yang diperlukan saat masuk, dan jaga daftarnya tetap singkat. Setiap kolom memperlambat respons pertama.
Buat matriks prioritas dan publikasikan bersama target respons.
Tetapkan kode resolusi sebelum go-live, bukan setelah enam bulan teks bebas.
Atur jendela auto-close untuk menunggu pelanggan.
Masukkan template respons sebagai balasan canned dan edit redaksinya agar terdengar seperti tim Anda.
Latih kategorisasi secara spesifik. Ini adalah kolom yang paling sering dilakukan dengan buruk dan yang paling penting.
Tinjau bucket Other setiap bulan untuk kuartal pertama.
Buat laporan kategori dan kode resolusi, bukan hanya volume.
Perbarui taksonomi setiap kuartal.
Praktik terbaik
Kategorikan saat pertama kali disentuh, perbaiki saat penutupan.
Batasi kolom masuk yang diperlukan hingga minimum yang membuat tiket bisa dikerjakan.
Turunkan prioritas dari dampak dan urgensi, bukan membiarkan agen memilih.
Gunakan kode resolusi, bukan teks bebas, untuk apa pun yang ingin Anda hitung.
Janjikan pembaruan, bukan resolusi.
Kirim pembaruan sebelum pelanggan mengejar.
Sebutkan penyebab di pesan resolusi.
Atur jendela auto-close untuk menunggu pelanggan.
Catat apakah artikel pengetahuan dibuat.
Buat laporan berdasarkan kategori dan kode resolusi.
Kesalahan yang umum
Kategori Other yang menampung sepertiga tiket.
Hierarki kategori empat level yang membuat agen berhenti membaca.
Kategori dinamai berdasarkan tim internal, bukan gejala pelanggan.
Prioritas dipilih bebas, sehingga semuanya menjadi tinggi.
Catatan resolusi teks bebas tanpa apa pun yang bisa dihitung.
Tidak ada pelacakan workaround, sehingga masalah yang belum terselesaikan menghilang.
Menunggu pelanggan tanpa auto-close, sehingga jumlah tiket terbuka membengkak tanpa batas.
Pesan resolusi yang mengatakan fixed tanpa menyebutkan apa yang salah.
Tidak ada tindak lanjut untuk masalah yang signifikan.
Pelaporan hanya volume, yang menunjukkan seberapa sibuk Anda dan tidak menjelaskan alasannya.
Kategorisasi retrospektif di akhir bulan.
Ubah tiket yang terselesaikan menjadi hal yang bisa diselesaikan pelanggan sendiri
Buka template di Trupeer AI, terapkan brand kit Anda agar semua yang ditujukan untuk pelanggan sesuai, lalu edit setiap bagian secara langsung. Penyiapannya ada di panduan template.
Lihat lagi tabel kode resolusi. Dokumentasi yang diberikan berarti jawabannya sudah ada dan tidak bisa ditemukan. Diselesaikan oleh dukungan, berulang kali, dalam kategori yang sama berarti jawabannya belum ada. Keduanya adalah masalah konten yang muncul sebagai volume dukungan, dan keduanya diperbaiki dengan cara yang sama.
Saat agen menyelesaikan sesuatu untuk keempat kalinya, catat sekali saja. Trupeer AI menghasilkan artikel tertulis dan video walkthrough yang dinarasikan dari proses yang sama, sehingga pelanggan berikutnya bisa menonton perbaikannya daripada membuat tiket. Terjemahkan ke 65+ bahasa, dan simpan set tersebut di knowledge base Anda agar mudah ditemukan saat seseorang sedang kesulitan. Gunakan rekaman yang sama untuk pelatihan agen.
Catat. Branding. Terjemahkan. Trupeer it.
Pertanyaan yang Sering Diajukan
Apakah ada template sistem ticketing gratis?
Ya. Versi Excel berfungsi sebagai log tiket lengkap untuk tim kecil tanpa alat helpdesk, dengan kategori, prioritas, kode resolusi, dan tab pelaporan. Jika Anda sudah memiliki sistem helpdesk, ambil daftar kolom dan template respons serta abaikan log.
Apakah ada template tiket help desk di Word?
Ya. File Word berisi form intake tiket, laporan resolusi, dan semua template respons, sehingga Anda bisa mencetak form atau menyalin redaksinya ke balasan canned helpdesk Anda.
Apakah ada template tiket service di Excel?
Ya, dan Excel adalah versi yang paling berguna untuk kebanyakan tim. Satu baris per tiket dengan kolom intake dan penutupan, dropdown untuk kategori, prioritas, dan kode resolusi, serta tab yang merangkum volume berdasarkan kategori dan jenis resolusi.
Apakah ada template tiket service di Word?
Ya. Versi Word menyertakan tiket service yang bisa dicetak, cocok untuk layanan lapangan atau dukungan walk-up, dengan garis tanda tangan untuk pekerjaan yang selesai dan persetujuan pelanggan.
Apakah ada template form tiket service IT?
Ya. Versi IT dari form intake menambahkan referensi aset atau perangkat, sistem yang terdampak, serta kolom referensi perubahan untuk service desk yang menjalankan proses perubahan formal.
Apakah ada template HTML atau Bootstrap untuk sistem tiket dukungan gratis?
Tidak, dan sebaiknya Anda bersikap langsung tentang hal itu. Permintaan tersebut untuk kode front-end guna membangun antarmuka ticketing, yang merupakan aset pengembangan web, bukan dokumen. Cari tema admin dashboard Bootstrap, atau gunakan platform helpdesk yang sudah ada, karena membangun sistem ticketing dari template biasanya lebih mahal daripada yang terlihat setelah Anda memperhitungkan autentikasi, routing email, dan logika SLA. Yang halaman ini berikan adalah desain kolom dan redaksi respons, yang tetap Anda perlukan apa pun antarmuka yang dibangun.
Apa itu template resolusi tiket?
Dua hal, tergantung konteks. Pesan resolusi yang dikirim ke pelanggan untuk menjelaskan apa yang salah dan apa yang dilakukan, serta catatan resolusi yang dicatat secara internal dengan kode resolusi, akar masalah, dan waktu hingga resolusi. Keduanya disertakan di sini, dan yang kedua adalah yang membuat data tiket Anda bisa digunakan.
Kolom apa saja yang harus dimiliki tiket dukungan?
Saat intake: ticket ID, tanggal, channel, peminta, akun, produk atau layanan, kategori, deskripsi dalam kata-kata pelanggan, prioritas, pemilik, dan status. Saat penutupan: kode resolusi, catatan resolusi, akar masalah jika diketahui, waktu respons dan resolusi, apakah tiket dibuka kembali, dan apakah artikel pengetahuan dibuat.
Bagaimana tiket dukungan harus dikategorikan?
Dua level, delapan hingga lima belas kategori tingkat atas, dinamai berdasarkan apa yang dialami pelanggan, bukan struktur tim internal Anda. Kategorikan saat pertama kali disentuh dan izinkan koreksi saat penutupan. Hindari bucket Other, atau tinjau setiap bulan dan promosikan item berulang menjadi kategori nyata.
Apa itu kode resolusi dan mengapa penting?
Sekumpulan nilai yang tetap untuk menjelaskan bagaimana tiket diselesaikan: fixed by support, fixed by engineering, documentation provided, workaround provided, user error, duplicate, no fault found. Kode ini penting karena catatan resolusi teks bebas tidak bisa dihitung, dan dua kode khususnya memberi tahu Anda di mana masalah sebenarnya berada.
Bagaimana cara menetapkan prioritas tiket?
Turunkan dari dampak dan urgensi menggunakan matriks yang dipublikasikan, bukan membiarkan agen memilih bebas. Dampak adalah seberapa banyak orang yang terdampak dan seberapa parah. Urgensi adalah seberapa cepat harus diselesaikan. Publikasikan matriks bersama target respons agar prioritas adalah perhitungan, bukan negosiasi.
Apa yang seharusnya dikatakan dalam pesan resolusi tiket?
Apa penyebabnya, apa yang Anda lakukan, apa yang seharusnya dilihat pelanggan sekarang, dan bagaimana cara menghubungi Anda jika masalah itu muncul lagi. Menyebutkan penyebab adalah bagian yang paling sering terlewat, dan itulah yang memberi pelanggan keyakinan bahwa perbaikan akan bertahan.
Berapa lama sebaiknya Anda menunggu sebelum menutup tiket?
Lima hingga sepuluh hari kerja untuk menunggu pelanggan, dengan pengingat sebelum penutupan dan pernyataan yang jelas bahwa membalas akan membukanya kembali. Tanpa jendela auto-close, jumlah tiket terbuka akan membengkak tanpa batas dan metrik waktu resolusi berhenti berarti apa pun.
Bisakah saya menyesuaikan tiket dan template resolusi ini?
Ya, semua versi sepenuhnya bisa diedit. Kategori dan kode resolusi adalah bagian yang harus menjadi milik Anda, dan disediakan sebagai set awal untuk diedit, bukan diadopsi secara menyeluruh. Di Trupeer AI, Anda juga bisa menerapkan brand kit agar pesan dan artikel yang ditujukan untuk pelanggan sesuai.
