Sistem Ticketing Customer Service: Cara Kerja, Fitur Wajib, dan Contoh Alur Eskalasi

Ringkasan artikel：Panduan ini menjelaskan cara kerja sistem ticketing customer service mulai dari pesan masuk, penetapan owner, prioritas, SLA, eskalasi, kolaborasi lintas tim, hingga penutupan tiket. Artikel juga membahas contoh status tiket dan matriks prioritas agar perusahaan dapat memetakan proses internal sebelum memilih aplikasi ticketing customer service. Selain itu, dibahas pula pentingnya histori perubahan, catatan internal, workflow, dan aturan eskalasi untuk mencegah tiket terlupakan. Cocok untuk Kepala Layanan Pelanggan, helpdesk, dan tim operasional yang ingin memahami bagaimana software ticketing pelanggan membantu pembagian kerja, pemantauan SLA, dan penyelesaian masalah secara lebih terstruktur.

Oleh Ardi Hermawan

Ardi Hermawan, Insinyur Implementasi di Udesk. Ia mengelola penerapan Udesk, konfigurasi alur tiket, pengaturan pusat panggilan cloud dan pelatihan onboarding pelanggan.

Sistem ticketing customer service biasanya mulai terasa perlu ketika email, WhatsApp, live chat, dan telepon menghasilkan terlalu banyak pekerjaan lanjutan. Ada pertanyaan yang selesai dalam dua menit, tetapi ada juga kasus yang harus pindah ke gudang, finance, teknisi, lalu kembali lagi ke CS. Kalau semuanya masih dicatat lewat inbox dan spreadsheet, tim cepat kehilangan jejak. Pertanyaannya kemudian bukan hanya “apa jawaban untuk pelanggan”, tetapi “siapa yang sedang pegang kasus ini” dan “kenapa belum selesai”.

Dari pesan masuk menjadi tiket

Tiket pada dasarnya adalah satu masalah pelanggan yang diberi identitas sendiri.

Pesan bisa datang dari email, WhatsApp, live chat, formulir web, telepon, atau kanal lain. Setelah masuk, kasus biasanya memiliki nomor tiket, nama pelanggan, kategori, waktu masuk, kanal, status, owner, dan riwayat percakapan.

Bedanya dengan inbox biasa cukup terasa saat volume mulai naik. Inbox menunjukkan pesan. Ticketing menjaga masalah tetap terlihat sampai memang selesai.

Pertanyaan seperti jam operasional tentu tidak perlu menjadi proses panjang. Tetapi kalau pelanggan menerima barang rusak dan perlu pemeriksaan gudang, kasusnya bisa melibatkan foto, nomor pesanan, pengecekan stok, sampai keputusan refund. Kasus seperti ini lebih aman tetap dibuka sampai ada hasil.

Satu tiket tetap harus punya pemilik

Masalah yang cukup sering muncul adalah semua orang merasa tiket sedang dikerjakan orang lain.

Agen frontline sudah meneruskan ke teknisi. Teknisi merasa ia hanya diminta memberi informasi. Supervisor mengira agen pertama masih memantau. Akhirnya tiket diam.

Karena itu, satu owner utama tetap berguna meskipun beberapa tim ikut terlibat.

Untuk tim kecil, assignment manual masih cukup. Begitu jumlah agen dan kategori bertambah, pembagian otomatis mulai lebih masuk akal. Aturannya bisa berdasarkan kategori, produk, bahasa, wilayah, skill, jumlah tiket aktif, atau round-robin.

Udesk Ticketing, misalnya, mendukung intelligent assignment berdasarkan workload dan skill serta shared ownership untuk pekerjaan lintas tim.

Shared ownership bukan berarti tanggung jawab menjadi kabur. Kalau belum terlihat siapa yang membawa kasus sampai selesai, berarti tiket belum benar-benar ditugaskan.

Status jangan dibuat terlalu banyak

Saat pertama menyusun workflow, perusahaan kadang ingin mencatat semua kondisi lewat status. Akhirnya muncul “waiting finance”, “checking warehouse”, “pending approval”, “follow up tomorrow”, dan banyak variasi lain.

Beberapa bulan kemudian agen sendiri lupa perbedaannya.

Untuk banyak tim, struktur dasar sudah cukup.

Status	Arti dalam pekerjaan sehari-hari
Baru	Tiket masuk dan belum mulai dikerjakan
Sedang ditangani	Sudah ada owner dan pekerjaan berjalan
Menunggu pelanggan	Masih membutuhkan informasi pelanggan
Menunggu internal	Kasus sedang menunggu tim lain
Selesai	Jawaban atau solusi sudah diberikan
Ditutup	Tidak ada pekerjaan lanjutan

Kalau butuh detail tambahan, field, tag, atau subkategori biasanya lebih praktis daripada menambah status baru.

Status “menunggu” juga jangan menjadi tempat tiket menghilang. Owner awal tetap perlu tahu kasus tersebut belum benar-benar selesai.

Prioritas jangan mengikuti siapa yang paling keras

Pelanggan mengirim pesan lima kali belum tentu berarti kasusnya kritis.

Kalau semua komplain diberi label urgent, label tersebut akhirnya tidak berguna. Lebih masuk akal melihat dampak masalah dan seberapa cepat tindakan memang dibutuhkan.

Prioritas	Contoh kondisi	Cara menangani
P1 Kritis	Layanan utama gagal untuk banyak pelanggan	Langsung dieskalasi
P2 Tinggi	Pelanggan penting tidak bisa memakai fungsi utama	Didahulukan
P3 Normal	Dampak terbatas atau ada workaround	Ikuti SLA reguler
P4 Rendah	Pertanyaan informasi atau nonmendesak	Ikuti antrean

P1 sampai P4 bukan aturan universal. Bisnis logistik, SaaS, e-commerce, dan perbankan tentu punya ukuran dampak berbeda.

Yang penting, prioritas punya alasan yang bisa dijelaskan dan tidak berubah hanya karena penilaian pribadi agen.

SLA bukan sekadar angka laporan

SLA sering baru diperhatikan ketika laporan bulanan menunjukkan pelanggaran. Padahal manfaat terbesarnya justru sebelum itu terjadi.

Biasanya perlu dibedakan response SLA dan resolution SLA. Respons pertama menjawab berapa lama pelanggan menunggu tanggapan. Resolution SLA berbicara tentang kapan masalah seharusnya selesai.

Agen bisa membalas dalam lima menit tetapi masalah teknisnya baru selesai dua hari kemudian. Dua angka ini menceritakan hal yang berbeda.

Sistem ticketing sebaiknya dapat menghitung tenggat berdasarkan jam kerja, kategori, dan prioritas. Udesk memungkinkan deadline respons dan penyelesaian disesuaikan berdasarkan business hours dan kategori tiket.

Peringatan sebelum SLA habis biasanya lebih berguna daripada laporan sesudahnya. Supervisor masih punya waktu untuk mengambil tindakan.

Contoh eskalasi yang cukup realistis

Bayangkan pelanggan menghubungi CS karena aplikasi kurir menunjukkan paket sudah terkirim, tetapi barang belum diterima.

Agen mengecek nomor pesanan dan histori pengiriman. Kalau informasinya belum cukup, tiket diteruskan ke tim logistik dan status berubah menjadi menunggu internal. Owner utama tetap terlihat.

Tim logistik kemudian menambahkan hasil pengecekan di dalam tiket, misalnya paket ternyata dititipkan ke security atau terjadi kesalahan scan.

Kalau informasi seperti ini hanya dikirim lewat chat pribadi, agen lain bisa kehilangan konteks saat kasus berpindah tangan.

Ketika SLA mulai mendekati batas, supervisor mendapat notifikasi. Untuk paket bernilai tinggi atau ada dugaan kehilangan, prioritas dapat dinaikkan sesuai aturan.

Setelah investigasi selesai, agen menghubungi pelanggan kembali. Tiket baru ditandai selesai setelah solusi atau keputusan sudah disampaikan.

Alurnya tidak perlu dibuat terlalu canggih. Workflow yang terlalu rumit malah sering membuat agen mencari jalan pintas di luar sistem.

Jangan lupa tiket yang dibuka kembali

Ada tiket yang terlihat selesai lalu pelanggan kembali keesokan hari.

Misalnya agen sudah memberi langkah troubleshooting dan menutup kasus, tetapi masalah muncul lagi. Kalau sistem langsung membuat tiket baru tanpa menghubungkannya dengan kasus sebelumnya, histori menjadi terpecah.

Karena itu, aturan reopen sebaiknya ditentukan sejak awal. Apakah balasan dalam tiga hari membuka tiket lama kembali, atau tetap dibuat kasus baru? Jawabannya bisa berbeda di setiap bisnis.

Duplicate ticket juga cukup umum. Pelanggan mengirim email lalu beberapa menit kemudian menghubungi WhatsApp karena merasa belum mendapat respons. Tanpa mekanisme merge atau identifikasi pelanggan, dua agen bisa mengerjakan masalah yang sama.

Catatan internal harus bisa dipahami orang lain

Catatan “sudah dicek” sebenarnya tidak banyak membantu.

Dicek apa, siapa yang mengecek, dan hasilnya bagaimana?

Catatan yang lebih berguna bisa sesederhana: “Sudah konfirmasi ke gudang pukul 14.20. Barang masih ada. Menunggu approval pengiriman ulang dari supervisor.”

Agen lain langsung tahu posisi kasus tanpa membaca semuanya dari awal.

Perubahan owner, status, waktu eskalasi, dan tindakan tim lain juga perlu tersimpan. Kalau pelanggan menelepon lagi tiga hari kemudian, agen baru tidak harus bertanya ulang dari nol.

Udesk menyediakan workflow, customizable agent roles, SLA management, shared ownership, dan integrasi sistem untuk kebutuhan seperti ini.

Kasus J&T Express memberi gambaran bagaimana kebutuhan tersebut muncul pada operasi yang lebih besar. Menurut studi kasus resmi Udesk, J&T membutuhkan sistem layanan yang lebih stabil ketika skala operasinya berkembang. Process automation dan intelligent routing digunakan untuk membantu pengelolaan customer service. Kasus tersebut tentu bukan jaminan hasil untuk perusahaan lain, tetapi cukup relevan sebagai contoh bahwa routing dan workflow makin penting saat volume meningkat.

Backlog jangan kalah perhatian dari tiket baru

Tim sering fokus pada tiket yang masuk hari ini, padahal tiket lama yang tidak bergerak bisa lebih bermasalah.

Lihat berapa banyak kasus yang sudah terbuka satu hari, tiga hari, atau satu minggu. Periksa juga status mana yang paling banyak menahan tiket.

Kalau backlog banyak berada di “menunggu internal”, mungkin masalahnya bukan kekurangan agen CS, tetapi proses antar-departemen yang lambat. Kalau banyak tiket dibuka kembali, bisa jadi solusi pertama belum cukup jelas.

Data ticketing lebih berguna ketika dipakai untuk menemukan pola seperti ini, bukan hanya menghitung volume tiket.

Sebelum demo vendor, buka tiket lama dulu

Sebelum memilih software ticketing pelanggan, ambil sepuluh kasus lama yang pernah membuat tim kerepotan.

Lihat dari mana kasus masuk, siapa yang menerima pertama, berapa kali owner berubah, informasi apa yang hilang saat handoff, kapan SLA mulai dihitung, dan siapa yang akhirnya menutup kasus.

Biasanya dari sini requirement menjadi lebih jelas.

Tim mungkin merasa membutuhkan AI, tetapi masalah utamanya ternyata assignment tidak konsisten. Bisa juga perusahaan ingin dashboard baru, padahal yang paling dibutuhkan adalah aturan eskalasi yang lebih jelas.

Untuk tim yang menangani tiket dari beberapa kanal dan sering melibatkan customer service, operasional, teknisi, finance, atau supervisor, Udesk dapat dipertimbangkan karena menyediakan assignment, SLA management, shared ownership, workflow, agent roles, dan integrasi dalam satu lingkungan. Manfaatnya paling terasa ketika satu kasus harus berpindah tangan beberapa kali tetapi owner, histori, dan tenggatnya tetap dapat dilihat tanpa bergantung pada chat pribadi atau spreadsheet tambahan.

FAQ

Q:Apa fungsi utama sistem ticketing customer service?

A:Sistem ticketing membantu tim menyimpan masalah pelanggan sebagai kasus yang memiliki owner, status, prioritas, SLA, dan histori sampai benar-benar selesai.

Q:Apakah semua pesan pelanggan harus menjadi tiket?

A:Tidak. Pertanyaan sederhana bisa selesai langsung. Ticketing lebih berguna untuk kasus yang membutuhkan tindak lanjut, eskalasi, atau kerja beberapa tim.

Q:Apa perbedaan prioritas dan SLA?

A:Prioritas menunjukkan tingkat dampak atau urgensi kasus. SLA menentukan batas waktu yang digunakan tim untuk memantau respons dan penyelesaiannya.

Kelola tiket pelanggan dengan cepat dan teratur menggunakan Sistem Tiket Udesk. Gratis coba 7 hari, tanpanya syarat!

Artikel ini merupakan karya asli Udesk. Jika akan diterbitkan ulang, wajib selalu mencantumkan sumber aslinya：https://id.udeskglobal.com/blog/sistem-ticketing-customer-service-cara-kerja-fitur-wajib-dan-contoh-alur-eskalasi