Seperti Apa QA Scorecard yang Dirancang untuk Machine Scoring, Bukan untuk Reviewer Manusia

Published on:
September 15, 2026

QA scorecard yang dibangun untuk machine scoring membutuhkan kriteria yang objektif dan bisa diverifikasi langsung dari transcript (apakah agent mengucapkan X, apakah agent melakukan Y dalam Z giliran bicara), bukan penilaian subjektif, karena model hanya bisa men-score apa yang dapat ditemukan dan diverifikasi dalam teks percakapan. Sebagian besar scorecard yang dipakai saat ini ditulis untuk reviewer manusia yang duduk dengan checklist dan menilai beberapa ticket. Ketika scorecard yang sama diarahkan ke mesin AutoQA, kriteria yang ambigu (tone "profesional", agent menunjukkan "empati") menghasilkan score yang tidak konsisten. Bukan karena modelnya lemah, tapi karena QA scorecard tersebut memang tidak pernah dirancang agar bisa diperiksa mesin. Di Revelir AI, kami men-score 100% percakapan customer service untuk perusahaan seperti Xendit dan Tiket.com, dan membangun ulang scorecard untuk machine scoring, bukan sekadar menerjemahkannya, adalah faktor tunggal terbesar yang kami lihat mendorong akurasi scoring di production.

Ringkasan

  • Scorecard buatan manusia mengandalkan penilaian subjektif ("terdengar empatik"); scorecard yang bisa di-machine-score butuh kriteria biner yang bisa diverifikasi dari transcript, bukan sekadar kesan.
  • Framework industri seperti 4Cs tetap berlaku, tapi AutoQA bekerja paling baik ketika setiap kriteria ditulis ulang sebagai pemeriksaan ya/tidak atau berskala yang terikat pada bahasa policy tertentu, bukan sekadar rasa [verint.com][balto.ai].
  • QA manual hanya meninjau 1 hingga 5% percakapan; scorecard yang dirancang untuk machine scoring adalah yang membuat coverage 100% menjadi mungkin.
  • AI menghilangkan reviewer fatigue dan variasi antar-reviewer, tapi QA scorecard tetap perlu mengompensasi hal-hal yang tidak dikuasai AI dengan baik, seperti membaca subteks emosional, lewat sub-kriteria yang eksplisit.
  • Scorecard sebaiknya diambil (retrieved) berdasarkan SOP aktual perusahaan pada saat scoring berlangsung, bukan di-hardcode sekali saja, sehingga AI menilai berdasarkan policy terkini, bukan template usang.

Tentang Penulis: Artikel ini ditulis oleh tim Revelir AI, yang membangun RevelirQA, platform AI quality assurance yang men-score 100% percakapan customer service berdasarkan SOP milik perusahaan itu sendiri. Scorecard Revelir berjalan di production di berbagai platform fintech dan travel yang menangani ribuan ticket per minggu dalam bahasa Inggris, Indonesia, Thailand, dan Tagalog.

Kenapa QA Scorecard untuk Manusia Tidak Bisa Langsung Dipakai untuk Scoring AI?

Scorecard yang dirancang untuk reviewer manusia mengasumsikan reviewer membawa konteks yang tidak tertulis di dokumen. Kriteria seperti "agent menangani customer secara profesional" berjalan baik ketika seorang QA lead punya pengalaman bertahun-tahun mendengarkan panggilan sebagai acuan kalibrasi. Large language model tidak punya kalibrasi tak tertulis semacam itu; yang dimilikinya hanya kata-kata di depannya dan instruksi di scorecard. Minta model menilai "profesionalisme" tanpa definisi, dan ia akan menghasilkan score yang terdengar masuk akal tapi belum tentu punya makna yang sama dari satu ticket ke ticket lain. Riset industri soal desain scorecard menegaskan pembagian ini secara langsung: scorecard yang ditinjau manusia bisa menilai nuansa emosional yang subjektif, sementara scorecard otomatis perlu dibangun di sekitar kriteria objektif berbasis transcript, seperti pemeriksaan compliance biner dan kepatuhan terhadap script. Ini bukan keterbatasan yang harus disiasati. Ini adalah batasan desain yang seharusnya membentuk seluruh scorecard sejak baris pertama.

Apa yang Membuat Sebuah Kriteria "Bisa Di-Machine-Score"?

Kriteria yang bisa di-machine-score adalah kriteria yang score-nya bisa diturunkan sepenuhnya dari bukti yang ada di transcript, tanpa mengharuskan model menebak niat atau menyimpulkan sesuatu yang tidak pernah disebutkan. Ini adalah uji desain intinya: apakah dua reviewer berbeda, yang sama-sama hanya membaca transcript dan teks kriteria, bisa sepakat pada score yang sama? Jika jawabannya bergantung pada nada suara, norma perusahaan yang tidak tertulis, atau "membaca di antara baris", kriteria itu belum siap untuk automated scoring. Ciri-ciri kriteria yang machine-scorable dengan baik:

  • Biner sebisa mungkin. "Apakah agent mengonfirmasi account ID customer sebelum memproses refund? Ya/Tidak" lebih baik daripada "Agent memverifikasi identitas customer dengan tepat."
  • Berpatokan pada bahasa policy yang spesifik. Kriteria merujuk pada jendela refund, kalimat disclosure, atau trigger escalation yang persis sesuai SOP, bukan parafrase.
  • Dibatasi pada momen yang bisa ditemukan. "Dalam dua giliran bicara agent pertama" atau "sebelum ticket ditutup" memberi model titik acuan untuk dicek, alih-alih memintanya menilai percakapan secara keseluruhan.
  • Bebas dari penilaian majemuk. Satu kriteria, satu hal yang diperiksa. "Agent bersikap sopan dan menyelesaikan masalah dengan efisien" sebenarnya menyelundupkan dua penilaian berbeda dalam satu baris.
Panduan industri soal desain scorecard mengarah ke kategori yang sama yang sudah dipakai tim manusia, seperti kualitas greeting, communication skills, kepatuhan proses, dan penyelesaian masalah [balto.ai]. Perubahan untuk machine scoring bukan pada kategorinya, melainkan pada penulisan ulang setiap kategori, dari deskripsi kualitas menjadi deskripsi bukti.

Bagaimana Kategori QA Scorecard Perlu Berubah untuk Automated Scoring?

Melanjutkan penulisan ulang kriteria di atas, pertanyaan yang lebih sulit adalah apakah seluruh kategori perlu direstrukturisasi, bukan sekadar diubah kata-katanya. Framework QA standar cenderung mengelompokkan kriteria di bawah header seperti greeting and introduction, communication skills, process and compliance, dan problem-solving [balto.ai], mengikuti pemikiran balanced-scorecard yang mengelompokkan metric berdasarkan dimensi strategis, bukan men-score semuanya dengan cara yang sama [balancedscorecard.org]. Pengelompokan itu tetap berlaku untuk auto QA, tapi setiap kategori butuh mekanisme scoring berbeda tergantung seberapa mudah diverifikasi:

Kategori Versi untuk reviewer manusia Versi machine-scorable
Greeting/pembukaan "Pembukaan yang hangat dan profesional" Pemeriksaan biner untuk disclosure wajib atau frasa pembuka yang diwajibkan brand
Process/compliance "Mengikuti prosedur dengan tepat" Checklist langkah policy spesifik yang disebutkan dari SOP, masing-masing di-score terpisah
Communication skills "Berkomunikasi dengan jelas dan empatik" Dipecah menjadi sub-pemeriksaan terpisah: jargon dihindari, pertanyaan customer diulang kembali, permintaan maaf hadir jika policy mensyaratkannya
Resolution "Menyelesaikan masalah dengan memuaskan" Apakah ticket mencapai status resolusi yang didefinisikan SOP, dalam batas giliran bicara atau waktu yang ditentukan policy
Di sinilah scoring berdasarkan dokumen policy aktual perusahaan, bukan template industri generik, menjadi paling penting. Kriteria seperti "mengikuti prosedur refund" hanya bisa di-machine-score jika model bisa mengambil (retrieve) SOP refund spesifik milik perusahaan tersebut pada saat scoring berlangsung. Ini adalah prinsip desain di balik pendekatan RevelirQA: policy dan SOP dimasukkan ke dalam vector database, dan AI mengambil SOP yang relevan sebelum men-score setiap percakapan, sehingga scorecard tidak memeriksa berdasarkan QA scorecard generik yang statis dan menjadi usang begitu policy berubah.

Apa yang Bisa Dicapai Scorecard yang Di-Machine-Score dan Tidak Bisa Dicapai Sampling Manual?

Melangkah mundur dari mekanisme scorecard, pertanyaan terkait lainnya adalah apa sebenarnya manfaat pekerjaan desain ini bagi tim QA. Jawaban jujurnya dimulai dari coverage. Sampling QA manual biasanya hanya meninjau 1 hingga 5% dari total percakapan, artinya masalah scorecard, pergeseran policy, atau kesenjangan training bisa luput terdeteksi di 95 sampai 99% sisanya selama berminggu-minggu. Scorecard yang direkayasa untuk machine scoring adalah yang membuat peninjauan 100% percakapan menjadi mungkin sejak awal, karena kriterianya murah dan konsisten untuk diperiksa dalam skala besar. Keuntungan kedua adalah konsistensi itu sendiri: model machine learning menerapkan QA scorecard yang sama tanpa fatigue, mood, atau perbedaan antar-reviewer, menghasilkan scoring yang seragam di setiap agent dan setiap shift. Platform auto QA milik Zendesk sendiri, yang terintegrasi dalam Zendesk QA, adalah pengakuan langsung dari industri terhadap pergeseran ini, menggunakan AI untuk men-score semua interaksi berdasarkan kriteria yang telah ditentukan, bukan sekadar sampel. Salesforce Service Cloud umumnya mencapai hasil serupa lewat integrasi AppExchange seperti Leaptree atau In-gage, bukan lewat tool native. Pola di seluruh industri sama: automated quality assurance scoring menjadi ekspektasi default, bukan lagi fitur tambahan yang eksperimental.

Apa yang Tetap Perlu Diserahkan ke Penilaian Manusia?

Bukan berarti scorecard harus dirancang agar model menangani semuanya. Studi industri konsisten pada poin ini: AI menghilangkan variabilitas manusia dalam menerapkan QA scorecard, tapi sering kali kekurangan penalaran kontekstual dan intuisi emosional yang dibawa reviewer manusia pada kasus yang benar-benar ambigu. Respons praktisnya bukan meninggalkan automated scoring untuk momen-momen tersebut, melainkan merancang scorecard sehingga momen itu ditandai (flagged) untuk manusia, bukan diam-diam salah di-score. Scorecard mesin yang dirancang dengan baik sebaiknya mencakup:

  • Escalation flag untuk percakapan di mana sentiment turun tajam atau kriteria tidak bisa diselesaikan dari transcript.
  • Reasoning trace yang melekat pada setiap score, menunjukkan dokumen policy mana yang diambil dan alasan model memberi score tertentu, sehingga QA lead bisa mengaudit ketidaksepakatan alih-alih menebak logika model.
  • Pelacakan sentiment arc (awal versus akhir percakapan), yang menangkap customer yang secara teknis "terselesaikan" menurut policy tapi tetap merasa frustrasi, pola yang akan luput sepenuhnya jika hanya mengandalkan checkbox resolusi biner.
Di sinilah auditability berhenti menjadi sekadar nilai tambah. Di industri yang diregulasi ketat seperti fintech, scorecard yang menghasilkan score tanpa reasoning yang terlihat adalah risiko compliance, bukan sekadar celah QA. RevelirQA melampirkan trace lengkap, yaitu model yang digunakan, SOP yang diambil, dan reasoning yang diterapkan, pada setiap score, dan inilah salah satu alasan platform ini sudah berjalan di workflow QA production pada perusahaan fintech seperti Xendit.

FAQ

Bisakah saya langsung memakai ulang QA scorecard yang sudah ada untuk AutoQA?
Bisa dimulai dari situ, tapi sebagian besar kriteria perlu ditulis ulang. Deskripsi subjektif seperti "ditangani secara profesional" perlu diubah menjadi pernyataan spesifik yang bisa diperiksa dari transcript sebelum model bisa men-score-nya secara konsisten.

Apakah automated quality assurance sepenuhnya menggantikan reviewer QA manusia?
Tidak. AutoQA menggantikan sampling manual, meninjau setiap percakapan alih-alih hanya 1 hingga 5%, tapi reviewer manusia tetap penting untuk mengalibrasi QA scorecard, menangani edge case yang di-flag, dan melakukan coaching agent berdasarkan hasil yang ditemukan dari score.

Apa perbedaan antara AutoQA dan auto QA?
Keduanya sama, hanya ditulis berbeda. AutoQA (satu kata) dan auto QA (dua kata) sama-sama merujuk pada automated quality assurance yang men-score percakapan berdasarkan QA scorecard tanpa sampling manual.

Berapa banyak kriteria yang sebaiknya dimiliki scorecard yang machine-scorable?
Kriteria yang lebih sedikit namun lebih spesifik umumnya berkinerja lebih baik dibanding daftar panjang kriteria yang luas, karena setiap kriteria perlu bisa diverifikasi secara independen dari transcript.

Bisakah scorecard yang dibangun untuk machine scoring menilai chatbot AI selain agent manusia?
Bisa, asalkan kriterianya berbasis policy, bukan terikat pada perilaku manusia seperti nada suara. RevelirQA, misalnya, men-score agent AI dan agent manusia pada QA scorecard yang sama, memberikan CX leader satu pandangan yang konsisten atas kualitas di kedua sisi.

Apakah QA scorecard perlu berubah saat policy perusahaan berubah?
Ya, dan ini adalah titik kegagalan yang umum terjadi. Scorecard yang di-hardcode pada versi policy dari beberapa bulan lalu akan terus men-score berdasarkan aturan yang sudah usang. Mengambil (retrieve) SOP terkini pada saat scoring berlangsung menghindari pergeseran semacam ini.

Tentang Revelir AI

Revelir AI membangun RevelirQA, platform AI quality assurance untuk customer service yang men-score 100% percakapan support berdasarkan policy dan SOP milik perusahaan sendiri, diambil lewat RAG sebelum setiap evaluasi. Didirikan pada 2025 oleh Rasmus Chow dan berkantor pusat di Singapura, Revelir sudah berjalan di production pada perusahaan seperti Xendit dan Tiket.com, men-score ribuan ticket per minggu dalam bahasa Inggris, Indonesia, Thailand, dan Tagalog. Setiap score membawa reasoning trace lengkap, yaitu model, dokumen yang diambil, dan reasoning-nya, memberi tim QA dan compliance catatan yang bisa diaudit di balik setiap evaluasi. Platform ini men-score agent manusia maupun chatbot AI pada scorecard yang sama, dan terintegrasi dengan helpdesk apa pun, termasuk Zendesk dan Salesforce, lewat API.

Jika QA scorecard Anda dibangun untuk reviewer dengan clipboard dan perlu dibangun ulang untuk model yang men-score setiap ticket, hubungi Revelir AI untuk mendiskusikan bagaimana penerapannya bagi policy perusahaan Anda.

Referensi

  1. How to Build Call Center QA Scorecards for Better CX | Verint (verint.com)
  2. Call Center Quality Monitoring Scorecard Best Practices | Balto (balto.ai)
  3. Balanced Scorecard Basics (balancedscorecard.org)