AI Quality Assurance untuk Customer Service: Dari Sampling ke Evaluasi 100% Percakapan

Ringkasan artikel：Panduan ini membahas AI quality assurance customer service dan cara berpindah dari sampling manual ke evaluasi percakapan otomatis dalam skala lebih besar. Fokusnya mencakup transkripsi, scorecard otomatis customer service, pemeriksaan kata wajib, sentiment, compliance, bias, false positive, review manusia, dan proses kalibrasi model. Artikel juga menjelaskan desain pilot sederhana untuk membandingkan hasil AI dengan reviewer manusia serta metrik seperti agreement rate, false positive, false negative, coverage, dan waktu review. Cocok untuk QA leader, contact center director, dan tim AI/DX yang ingin menerapkan evaluasi percakapan otomatis tanpa kehilangan kontrol manusia pada kasus sensitif.

Oleh Rizki Firmansyah

Rizki Firmansyah, Spesialis Produk AI Udesk. Ia meneliti penerapan LLM di pusat kontak, termasuk chatbot AI, basis pengetahuan dan pemeriksaan kualitas percakapan berbasis AI.

AI quality assurance customer service mulai menarik ketika tim QA sadar mereka hanya melihat sebagian kecil dari apa yang sebenarnya terjadi di contact center. Bukan berarti review manual sudah tidak berguna, tetapi dengan ribuan call dan chat setiap hari, cukup banyak masalah yang memang tidak pernah masuk ke sampel.

Sampling manual sebenarnya masih berguna

QA manual punya satu kelebihan yang sulit digantikan: manusia cukup bagus membaca konteks.

Reviewer bisa memahami pelanggan sedang bercanda atau marah, agen menghadapi kasus yang tidak biasa, atau SOP memang tidak cocok dengan situasi tertentu. Hal seperti ini kadang tidak mudah dimasukkan ke rule.

Masalahnya ada di jumlah.

Kalau seorang agen menangani ratusan percakapan dalam seminggu dan QA hanya mendengar tiga atau lima call, skor akhirnya sangat bergantung pada call mana yang kebetulan terpilih. Bisa saja agen melakukan pelanggaran serius di satu percakapan lain yang tidak pernah didengar reviewer.

Evaluasi percakapan otomatis mencoba mengurangi blind spot tersebut dengan memeriksa jauh lebih banyak interaction, bahkan seluruh percakapan yang datanya memang tersedia untuk dianalisis.

Jadi pilihannya bukan manusia atau AI. Yang lebih masuk akal adalah membagi pekerjaan.

Untuk voice, semuanya dimulai dari transkripsi

Chat sudah berbentuk teks. Call tidak.

Sebelum AI bisa memeriksa percakapan telepon, rekaman perlu diubah menjadi transcript melalui speech-to-text.

Di sinilah kualitas input sangat berpengaruh.

Nama produk, nomor pelanggan, istilah lokal, aksen, suara kendaraan, dua orang bicara bersamaan, atau sambungan telepon yang buruk dapat membuat transcript meleset. Kalau kata yang salah kebetulan berkaitan dengan compliance, efeknya bisa cukup besar.

Misalnya scorecard mencari kalimat verifikasi tertentu. Agen sebenarnya mengatakannya, tetapi transcription gagal mengenali bagian tersebut. Sistem bisa menandai call sebagai pelanggaran padahal prosesnya benar.

Karena itu, sebelum membicarakan scorecard otomatis customer service, lihat dulu kualitas transkripsinya pada rekaman perusahaan sendiri.

Ambil call yang gampang dan yang jelek. Jangan hanya menguji audio studio.

Rubrik otomatis jangan langsung meniru form manual 100%

Ini kesalahan yang cukup mudah terjadi.

Tim sudah punya scorecard manual dengan 25 pertanyaan, lalu semuanya langsung dimasukkan ke AI. Hasilnya belum tentu bagus.

Beberapa item memang relatif jelas.

Apakah agen menyebut informasi wajib? Apakah verifikasi dilakukan? Apakah ada kata yang dilarang? Apakah agen menawarkan langkah berikutnya? Apakah percakapan ditutup sesuai prosedur?

Hal seperti ini cukup cocok untuk otomatisasi awal.

Tetapi item seperti “agen menunjukkan empati yang tulus” lebih sulit. Ada konteks, nada suara, jenis masalah, bahkan budaya komunikasi yang ikut bermain.

Lebih aman membagi rubrik menjadi tiga kelompok: bagian yang bisa diperiksa dengan rule cukup jelas, bagian yang bisa dinilai AI tetapi perlu sampling manusia, dan bagian yang memang tetap lebih nyaman dinilai manusia.

Dengan begitu, tim tidak memaksa mesin membuat keputusan pada area yang masih abu-abu.

Kata wajib berguna, tapi jangan hanya mencari keyword

Misalnya perusahaan mewajibkan agen menjelaskan bahwa panggilan direkam.

Pencarian kata bisa dipakai sebagai pemeriksaan awal. Tapi agen mungkin memakai kalimat yang sedikit berbeda dengan arti yang sama.

Sebaliknya, kata tertentu bisa muncul tetapi sebenarnya bukan bagian dari disclosure yang benar.

Itulah sebabnya evaluasi berbasis keyword saja cepat mentok.

Model yang memahami konteks dapat membantu membaca apakah maksud wajib memang sudah disampaikan. Walaupun begitu, untuk hal dengan risiko compliance tinggi, hasil otomatis sebaiknya tetap punya jalur review manusia.

Terutama kalau satu flag bisa berujung pada coaching formal, penalti, atau tindakan disipliner.

Sentiment lebih cocok menjadi sinyal daripada vonis

Sentiment analysis memang menarik untuk monitoring call center.

Percakapan dengan emosi negatif dapat ditandai lebih cepat. Tim QA jadi tidak perlu mencari call bermasalah secara acak.

Tapi pelanggan marah bukan berarti agen bekerja buruk.

Pelanggan bisa marah karena paket terlambat, kebijakan refund, atau gangguan produk. Agen justru mungkin menangani situasi tersebut dengan sangat baik.

Begitu juga sebaliknya. Pelanggan yang terdengar tenang belum tentu menerima layanan yang benar.

Karena itu, sentiment lebih aman dipakai sebagai filter atau signal untuk review lanjutan. Jangan otomatis memotong skor agen hanya karena sistem membaca emosi negatif.

False positive harus dianggap normal pada awal pilot

AI QA yang baru diterapkan hampir pasti menghasilkan sebagian flag yang salah.

Itu bukan alasan langsung menghentikan proyek.

Yang penting, false positive dicatat.

Misalnya AI menandai 100 call karena dianggap tidak melakukan verifikasi. Setelah manusia memeriksa, ternyata 18 di antaranya sebenarnya benar.

Berarti precision pada rule tersebut masih perlu diperbaiki.

Tim bisa melihat kenapa. Mungkin banyak agen menggunakan frasa yang belum ada di rule. Mungkin transcription sering gagal pada satu istilah. Bisa juga prompt atau definisi kriterianya terlalu sempit.

Kalau kesalahan seperti ini tidak dihitung, dashboard terlihat sangat rapi tetapi kepercayaannya cepat hilang ketika agen mulai menemukan penilaian yang tidak masuk akal.

Bias juga bisa datang dari data dan desain rubrik

AI tidak otomatis membuat QA netral.

Kalau transcription lebih buruk pada aksen tertentu, hasil QA kelompok agen tertentu bisa ikut terdampak. Kalau rubrik dibangun dari contoh percakapan satu tim saja, gaya komunikasi tim lain mungkin dinilai kurang sesuai walaupun sebenarnya masih benar.

Masalah bias juga bisa muncul dari scorecard lama.

Kalau manusia sejak awal memakai indikator yang kurang jelas, otomatisasi hanya membuat aturan yang kurang jelas itu berjalan dalam skala lebih besar.

Karena itu, saat pilot sebaiknya bandingkan hasil berdasarkan tim, bahasa, channel, tipe percakapan, dan beberapa kelompok agen. Kalau selisihnya aneh, jangan langsung menyimpulkan performa mereka memang berbeda.

Periksa input dan rule-nya dulu.

Review manusia tetap perlu, hanya pekerjaannya berubah

Dalam model lama, QA mencari masalah dengan mendengarkan sampel.

Dalam model berbasis AI, manusia bisa lebih banyak memeriksa exception.

Misalnya sistem menganalisis seluruh percakapan lalu menandai call dengan risiko compliance, sentiment memburuk, kata tertentu, atau skor di bawah threshold.

QA kemudian masuk ke percakapan tersebut.

Ini membuat waktu reviewer lebih banyak dipakai pada kasus yang memang perlu perhatian.

Tetap sisakan random sample. Jangan hanya memeriksa call yang dianggap buruk oleh AI, karena tim juga perlu tahu apakah mesin gagal mendeteksi masalah pada percakapan yang terlihat normal.

Kalibrasi model jangan dipisahkan dari kalibrasi manusia

Tim QA biasanya sudah mengenal calibration session. Dua atau beberapa reviewer menilai call yang sama, lalu membandingkan hasil.

AI sebaiknya ikut masuk ke proses tersebut.

Pilih sejumlah percakapan. Minta reviewer manusia menilai tanpa melihat skor AI terlebih dahulu. Setelah selesai, baru bandingkan.

Kalau manusia memberi pass tetapi AI memberi fail, lihat alasannya.

Kadang AI salah. Kadang justru reviewer manusia melewatkan sesuatu.

Yang dicari bukan siapa yang menang, tetapi di bagian mana definisi kriterianya belum cukup jelas.

Kalibrasi seperti ini perlu diulang kalau SOP berubah, produk baru diluncurkan, atau tim mulai menggunakan bahasa dan channel berbeda.

Pilot tidak perlu langsung ke semua agen

Mulai dari satu queue atau satu jenis percakapan.

Misalnya customer service telepon untuk pertanyaan produk.

Ambil data beberapa minggu, lalu pilih lima sampai delapan kriteria yang cukup jelas. Contohnya opening, verifikasi, disclosure wajib, diagnosis dasar, solusi, dan closing.

Jalankan AI tanpa menjadikan skornya sebagai dasar appraisal lebih dulu.

Selama pilot, manusia masih menjadi pembanding.

Contoh ukuran yang bisa dicatat:

Sesudah beberapa minggu, baru putuskan kriteria mana yang sudah cukup stabil dan mana yang masih perlu review manual.

Kasus China Customs menunjukkan penggunaan intelligent quality inspection

Kasus resmi Udesk mengenai China Customs cukup relevan karena memang menyebut penggunaan intelligent quality inspection. Sebelum implementasi, beberapa platform layanan belum terintegrasi dan kemampuan analisis data juga terbatas. Dalam solusi yang digunakan, Udesk menerapkan inspeksi kualitas berdasarkan kriteria yang sudah ditentukan, sekaligus menyatukan analisis data layanan dari berbagai channel.

Halaman kasus tersebut tidak menjelaskan detail seperti false-positive rate, desain scorecard, atau persentase percakapan yang dianalisis. Jadi kasus ini lebih tepat dipakai sebagai contoh penerapan quality inspection berbasis rule dan data, bukan sebagai bukti bahwa otomatisasi selalu memberikan skor sempurna.

Jangan mengejar “100% otomatis” sebagai tujuan akhir

Menganalisis 100% percakapan dan mempercayai 100% keputusan AI adalah dua hal berbeda.

Coverage penuh berguna karena QA mendapat pandangan yang lebih luas. Tetapi keputusan yang sensitif tetap perlu mekanisme review, terutama untuk compliance, dispute, dan penilaian performa individu.

Tujuan yang lebih masuk akal adalah membuat masalah penting lebih cepat terlihat, mengurangi waktu yang habis untuk pemeriksaan rutin, dan memberi tim QA data yang lebih kaya untuk coaching.

Udesk sendiri menyediakan kemampuan Quality Assurance untuk memonitor dan mengevaluasi percakapan layanan secara otomatis, sementara materi resminya juga membahas penggunaan speech-to-text, rule-based checks, sentiment, dan analisis percakapan sebagai bagian dari automated QA. Untuk QA leader, contact center director, dan tim AI/DX yang ingin bergerak dari sampling ke evaluasi percakapan otomatis, Udesk dapat dipertimbangkan sebagai platform pilot. Yang penting, implementasinya tetap dimulai dari rubrik yang jelas, data nyata, kalibrasi manusia, dan mekanisme review ketika AI memberi hasil yang meragukan.

FAQ

Q:Apakah AI QA benar-benar bisa mengevaluasi seluruh percakapan?

A:Secara teknis, sistem dapat memproses seluruh percakapan yang tersedia dan memenuhi syarat analisis. Tetapi sebagian hasil tetap perlu review manusia, terutama untuk kasus kompleks dan berisiko tinggi.

Q:Apakah scorecard manual bisa langsung dipakai untuk AI?

A:Sebaiknya tidak langsung semuanya. Mulai dari kriteria yang cukup objektif, lalu uji agreement dengan reviewer manusia sebelum memperluas rubrik.

Q:Apa penyebab false positive pada evaluasi percakapan otomatis?

A:Penyebabnya bisa berupa transcription yang salah, definisi rule terlalu sempit, konteks yang tidak terbaca, atau variasi bahasa yang belum terwakili dalam data pilot.

Jawab pertanyaan pelanggan 24/7 tanpa henti dengan Chatbot AI Udesk. Coba gratis dan kurangi beban manual tim CS!

Artikel ini merupakan karya asli Udesk. Jika akan diterbitkan ulang, wajib selalu mencantumkan sumber aslinya：https://id.udeskglobal.com/blog/ai-quality-assurance-untuk-customer-service-dari-sampling-ke-evaluasi-100-percakapan