Voice of Customer: Cara Menggabungkan Tiket, Chat, Telepon, dan Survei Menjadi Insight

Ringkasan artikel：Panduan ini membahas cara membangun program voice of customer dari berbagai sumber, mulai dari tiket, chat, transkrip telepon, survei, hingga ulasan pelanggan. Fokusnya adalah membantu tim CX, product, dan customer service analytics mengubah percakapan yang tersebar menjadi insight yang bisa ditindaklanjuti. Artikel menjelaskan taksonomi topik, deduplikasi, sentiment, severity, volume, tren, root cause, ownership, serta closed-loop action. Contoh dashboard untuk tim produk dan operasi juga dibahas agar analisis VOC tidak berhenti di laporan. Dengan pendekatan customer feedback analytics yang lebih terstruktur, perusahaan dapat melihat masalah utama pelanggan, menentukan owner, dan memantau apakah tindakan perbaikan benar-benar membawa perubahan.

Oleh Siti Ayu

Siti Ayu, Manajer Keberhasilan Pelanggan di Udesk. Ia ahli dalam penerapan layanan pelanggan, mendukung merek manufaktur, ritel dan global untuk mengoptimalkan operasi dukungan serta CSAT.

Voice of customer sering dianggap sama dengan hasil survei, padahal sebagian masukan paling jujur justru muncul ketika pelanggan sedang mengeluh di chat, menelepon call center, atau menjelaskan masalah di tiket. Tantangannya bukan kekurangan feedback, tetapi bagaimana menyatukan semua percakapan itu supaya tim produk dan operasi tidak harus membaca ribuan baris satu per satu.

Jangan mulai dari dashboard, mulai dari sumber datanya

Sebelum bicara soal analisis VOC, lihat dulu tempat pelanggan sebenarnya berbicara.

Tiket biasanya cukup kaya konteks karena ada kategori kasus, status, produk, agen, dan hasil penyelesaian. Chat lebih spontan. Pelanggan bisa mengetik “fiturnya error lagi” tanpa menjelaskan produk mana sampai beberapa pesan berikutnya.

Telepon lebih rumit lagi. Data baru mudah dianalisis kalau recording sudah menjadi transcript. Sementara survei seperti CSAT atau NPS memang lebih rapi, tetapi jumlah responden biasanya jauh lebih kecil dibanding total percakapan layanan.

Ulasan marketplace, aplikasi, atau media sosial menambah sudut lain. Orang yang meninggalkan review belum tentu pernah membuat tiket.

Udesk VoC sendiri mendukung pengumpulan data dari online chat, percakapan telepon, tiket, email, ulasan e-commerce, media sosial, dan survei. Ini penting karena satu kanal saja biasanya tidak cukup menggambarkan pengalaman pelanggan secara keseluruhan.

Saat menggabungkan data, jangan buru-buru memasukkan semua field. Untuk tahap awal, simpan hal yang memang akan dipakai: waktu, kanal, customer ID jika tersedia, produk, teks percakapan, kategori kasus, hasil penyelesaian, CSAT, dan beberapa atribut pelanggan yang memang relevan.

Satu pelanggan bisa menghasilkan lima feedback untuk masalah yang sama

Ini bagian yang sering membuat angka terlihat lebih besar dari kondisi sebenarnya.

Seorang pelanggan menemukan error saat checkout. Ia membuka live chat, kemudian menelepon karena belum selesai. Malamnya ia memberi rating buruk di aplikasi. Besok pagi tiket dari chat masih terbuka.

Kalau setiap record dihitung sebagai satu masalah baru, dashboard akan mengatakan ada empat keluhan. Padahal akar masalahnya satu.

Karena itu, deduplikasi perlu dilakukan sebelum membaca volume.

Tidak harus sempurna. Mulai dengan customer ID, order ID, ticket ID, produk, topik, dan jarak waktu. Kalau tiga percakapan dari pelanggan yang sama membahas masalah checkout dalam dua hari, sistem bisa menandainya sebagai kemungkinan satu episode.

Untuk pelanggan anonim, matching memang lebih sulit. Jangan memaksa dua feedback menjadi satu hanya karena kalimatnya mirip.

Lebih baik ada sedikit duplikasi daripada salah menggabungkan dua pelanggan berbeda.

Taksonomi topik jangan dibuat terlalu pintar sejak awal

Tim sering ingin membuat daftar topik yang sangat lengkap.

Hasilnya bisa ratusan label: payment failed, payment pending, card rejected, wallet error, bank transfer problem, dan seterusnya. Setelah berjalan beberapa minggu, analis malah sibuk memperbaiki label.

Mulai dari struktur yang cukup sederhana.

Misalnya level pertama berisi Product, Payment, Delivery, Account, Refund, dan Service. Di bawah Payment baru ada failed transaction, delayed confirmation, atau metode pembayaran tidak tersedia.

Gunakan istilah yang benar-benar muncul di bisnis.

Kalau pelanggan di Indonesia sering mengatakan “saldo kepotong tapi transaksi gagal”, label internal seperti financial transaction exception mungkin terlalu jauh dari bahasa percakapan.

Taksonomi juga perlu bisa berubah. Kalau dalam tiga bulan muncul banyak keluhan baru tentang satu fitur, tambahkan subtopik. Jangan membuat ratusan kategori sebelum datanya sendiri menunjukkan kebutuhan itu.

Sentiment berguna, tetapi jangan dipakai sendirian

Kalimat negatif memang menarik perhatian, tetapi tidak semua keluhan negatif punya dampak yang sama.

“Warna tombolnya kurang bagus” bisa sangat negatif. “Saya tidak bisa masuk akun dan pembayaran jatuh tempo hari ini” mungkin ditulis dengan bahasa tenang.

Karena itu, customer feedback analytics sebaiknya tidak berhenti pada positive, neutral, dan negative.

Tambahkan severity.

Severity melihat dampak masalah. Apakah pelanggan hanya kurang nyaman? Apakah transaksi terhambat? Apakah banyak pengguna terdampak? Apakah ada risiko kehilangan uang, keselamatan, atau kegagalan layanan utama?

Sentiment memberi tahu bagaimana pelanggan merasakan masalah. Severity membantu menentukan seberapa cepat perusahaan harus bergerak.

Keduanya cukup berbeda.

Volume besar belum tentu masalah terbesar

Misalnya dashboard minggu ini menunjukkan tiga topik:

“Cara reset password” muncul 8.000 kali.

“Checkout lambat” muncul 1.200 kali.

“Pembayaran ganda” hanya muncul 80 kali.

Kalau hanya diurutkan berdasarkan volume, pembayaran ganda akan berada jauh di bawah. Tapi dari sisi risiko, 80 kasus tersebut mungkin jauh lebih serius.

Karena itu, analisis VOC perlu melihat beberapa sinyal sekaligus: volume, perubahan dibanding periode sebelumnya, severity, sentiment, jumlah pelanggan unik, repeat contact, dan mungkin nilai bisnis yang terdampak.

Tren juga lebih berguna daripada angka tunggal.

Keluhan mengenai fitur tertentu mungkin hanya 300 minggu ini. Tetapi kalau minggu lalu 50, kenaikannya layak diperiksa.

Pertanyaan yang lebih berguna bukan “topik mana paling banyak?”, melainkan “apa yang berubah dibanding kondisi normal?”

Root cause tidak selalu sama dengan kata yang paling sering muncul

Customer bilang “pengiriman terlambat”. Itu masih gejala.

Penyebabnya bisa stok belum tersedia, sistem warehouse terlambat mengirim data, kurir gagal pickup, alamat bermasalah, atau estimasi yang memang terlalu optimistis.

Di sinilah analisis VOC perlu bertemu data operasional.

Kalau keluhan keterlambatan naik, pecah lagi berdasarkan gudang, daerah, mitra pengiriman, produk, dan tanggal order.

Hal yang sama untuk produk digital. Banyak pelanggan mengatakan “tidak bisa login”. Root cause-nya mungkin bukan login sama sekali. Bisa jadi OTP tidak terkirim.

Jangan meminta AI menebak akar masalah hanya dari satu kalimat pelanggan. Gunakan percakapan sebagai sinyal awal, lalu cocokkan dengan data yang bisa menjelaskan kejadian tersebut.

Contoh dashboard untuk produk dan operasi

Satu dashboard besar untuk semua orang biasanya cepat penuh.

Product manager dan customer service operations sebenarnya membutuhkan tampilan berbeda.

Untuk product manager, satu grafik “jumlah tiket” kurang membantu. Ia lebih membutuhkan breakdown berdasarkan fitur dan versi produk.

Tim operasi mungkin tidak terlalu peduli feature request kecil, tetapi sangat perlu tahu alasan repeat contact atau kasus yang sering melewati SLA.

Udesk juga menyediakan reporting dan dashboard yang dapat dikustomisasi, sementara produk VoC-nya menggabungkan analisis serta visualisasi feedback dengan proses bisnis.

Insight tanpa owner biasanya berhenti di presentasi

Ini masalah yang sangat biasa.

Tim analytics menemukan keluhan tentang refund meningkat 35 persen. Grafik masuk ke laporan bulanan. Semua orang setuju masalahnya penting. Bulan berikutnya grafiknya masih sama.

Yang hilang bukan analisis, tetapi ownership.

Setiap insight yang dianggap perlu tindakan sebaiknya punya owner, deadline, dan status.

Misalnya:

“Keluhan refund naik setelah perubahan halaman pembayaran.”

Owner-nya mungkin Product dan Payment Operations. Mereka memeriksa penyebab, membuat perubahan, lalu tim VOC melihat apakah jumlah keluhan turun setelah perubahan dirilis.

Itu baru closed-loop action.

Closed loop tidak berarti semua feedback harus mendapat proyek baru. Ada feedback yang cukup dipantau. Yang penting keputusan tersebut terlihat jelas: investigate, fix, monitor, atau no action.

Produk VoC Udesk juga mencantumkan closed-loop management, role-based action plan, alert, dan tracking sebagai bagian dari proses membawa hasil analisis kembali ke operasi.

Kasus J&T menunjukkan nilai data ketika channel sudah disatukan

Kasus resmi Udesk tentang J&T Express memang bukan studi khusus tentang program VoC, jadi tidak perlu dipaksakan menjadi contoh sentiment analytics.

Bagian yang relevan ada pada datanya.

Menurut halaman kasus tersebut, pertanyaan J&T sebelumnya tersebar di telepon, website, WhatsApp, Facebook, dan Instagram. Setelah channel dan histori interaksi disatukan, Udesk menyebut data omnichannel tersebut digunakan untuk monitoring dan analisis kualitas layanan serta mendukung perbaikan berkelanjutan.

Ini cukup menggambarkan fondasi VOC yang sering dilupakan. Sulit mencari pola kalau setiap kanal masih mempunyai histori sendiri-sendiri.

Mulai dari satu pertanyaan bisnis, bukan semua data sekaligus

Program VOC tidak perlu dimulai dengan proyek besar.

Pilih satu pertanyaan yang memang sedang mengganggu bisnis. Misalnya, kenapa repeat contact naik setelah pelanggan melakukan refund? Atau fitur apa yang paling sering membuat pengguna baru menghubungi CS?

Ambil data tiket, chat, telepon, dan survei yang berkaitan. Buat taksonomi kecil. Bersihkan duplikasi. Lihat volume, severity, sentiment, dan tren. Setelah menemukan dugaan penyebab, serahkan ke owner yang bisa melakukan perubahan.

Bulan berikutnya, cek lagi.

Kalau keluhannya turun, ada sesuatu yang berhasil. Kalau tidak, mungkin root cause pertama salah.

Untuk perusahaan yang sudah menerima feedback dari banyak kanal, Udesk dapat dipertimbangkan karena produk Voice of Customer-nya memang dirancang untuk mengumpulkan data percakapan, tiket, telepon, survei, ulasan, dan kanal sosial, kemudian membawa hasil analisis kembali ke proses bisnis melalui visualisasi, alert, dan closed-loop management. Nilai utamanya bukan membuat dashboard lebih ramai, tetapi membantu analisis VOC bergerak dari “pelanggan banyak mengeluh soal ini” menjadi pertanyaan yang lebih berguna: masalahnya apa, siapa yang harus memperbaiki, dan apakah kondisinya benar-benar membaik setelah tindakan dilakukan.

FAQ

Q:Apa bedanya Voice of Customer dan survei pelanggan?

A:Survei hanya salah satu sumber Voice of Customer. VoC juga dapat berasal dari tiket, chat, telepon, review, email, dan percakapan lain yang terjadi selama customer journey.

Q:Apakah semua feedback harus dianalisis dengan sentiment?

A:Tidak. Sentiment berguna sebagai sinyal, tetapi sebaiknya dibaca bersama topik, severity, volume, tren, dan konteks kasus.

Q:Bagaimana menghindari satu masalah dihitung berkali-kali?

A:Gunakan customer ID, order atau ticket ID, topik, serta jarak waktu untuk mendeteksi percakapan yang kemungkinan berasal dari satu episode masalah yang sama.

Chatbot Suara Udesk dengan pengenalan suara akurat, layani pelanggan secara otomatis. Coba gratis dan rasakan kemudahannya!

Artikel ini merupakan karya asli Udesk. Jika akan diterbitkan ulang, wajib selalu mencantumkan sumber aslinya：https://id.udeskglobal.com/blog/voice-of-customer-cara-menggabungkan-tiket-chat-telepon-dan-survei-menjadi-insight