Agent Assist AI: Cara Membantu Agen Menjawab Lebih Cepat dan Konsisten

Ringkasan artikel：Panduan ini membahas cara kerja agent assist AI untuk membantu agen customer service menjawab lebih cepat dan konsisten tanpa menggantikan keputusan manusia. Pembahasan mencakup real-time transcription, intent detection, pencarian knowledge, next-best action, rekomendasi jawaban agen, serta perbedaan assistive AI dan chatbot otonom. Artikel juga menjelaskan pentingnya latency, confidence threshold, sumber jawaban, dan feedback agen dalam proses evaluasi. Cocok untuk Customer Service Director, tim Operations, dan AI Product Team yang ingin menjalankan pilot AI copilot customer service dengan KPI seperti AHT, FCR, adoption rate, serta tingkat penerimaan rekomendasi.

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.

Agent assist AI biasanya mulai terasa perlu bukan karena perusahaan ingin “memakai AI”, tetapi karena agen terlalu sering berhenti di tengah percakapan. Kadang mereka harus membuka tiga tab untuk mencari SOP, kadang bertanya ke supervisor, kadang malah memakai jawaban lama karena itu yang paling cepat ditemukan. Di situ AI copilot customer service bisa membantu. Bukan mengambil alih percakapan, melainkan memberi bahan agar agen tidak terlalu banyak mencari sendiri.

Agent assist sebenarnya cukup sederhana

Chatbot berbicara langsung dengan pelanggan. Agent assist tidak.

Pelanggan tetap dilayani manusia. Bedanya, saat agen sedang menangani chat atau telepon, sistem bisa ikut membaca konteks lalu membantu mencari informasi yang mungkin dibutuhkan.

Misalnya pelanggan bilang, “tagihan saya bulan ini kok beda ya”.

Agen tetap yang menjawab. Di belakang layar, sistem mencoba memahami bahwa topiknya berkaitan dengan billing, lalu menampilkan artikel atau prosedur yang kemungkinan relevan. Kalau ada langkah tertentu yang biasa dilakukan setelah itu, sistem juga bisa menyarankannya.

Agen bebas memakai saran tersebut atau tidak.

Ini justru bagian yang menurut saya paling masuk akal dari agent assist. Tidak semua percakapan customer service cocok diserahkan penuh kepada bot. Pertanyaan biasa bisa tiba-tiba berubah menjadi komplain, sementara komplain bisa membutuhkan approval supervisor. AI membantu di bagian yang repetitif, manusia tetap menangani bagian yang butuh pertimbangan.

Di voice, transcription jadi pintu masuk

Kalau agent assist dipakai di telepon, suara pelanggan perlu diubah menjadi teks terlebih dahulu.

Di atas kertas terdengar mudah. Di lapangan, pelanggan sering bicara cepat, memotong kalimat sendiri, memakai istilah campuran, atau memberi informasi sedikit demi sedikit.

Misalnya pelanggan tidak bilang “saya ingin mengajukan refund”. Ia bisa saja bilang, “ini barangnya salah kirim, terus saya mesti gimana?”

Sistem harus menangkap maksudnya sebelum bisa mencari knowledge yang cocok.

Setelah intent mulai terbaca, AI biasanya mencari artikel, SOP, atau informasi lain yang berkaitan. Dari situ bisa muncul rekomendasi jawaban agen atau next-best action, misalnya verifikasi identitas, cek data di CRM, atau buat tiket ke tim tertentu.

Untuk chat, prosesnya lebih ringan karena tidak ada tahap transcription. Tetapi masalah dasarnya tetap sama, yaitu apakah sistem benar-benar memahami konteks percakapan dan menemukan sumber yang tepat.

Kalau knowledge-nya berantakan, AI juga ikut berantakan

Jawaban AI sering terlihat rapi. Itu kadang membuat orang terlalu cepat percaya.

Masalahnya, kalimat yang terdengar bagus belum tentu berasal dari sumber yang benar.

Kalau perusahaan masih punya dua versi SOP refund yang sama-sama aktif, agent assist bisa mengambil salah satunya. Kalau artikel produk sudah enam bulan tidak diperbarui, AI juga bisa menyarankan informasi yang sebenarnya sudah lewat.

Karena itu, rekomendasi sebaiknya tetap punya sumber yang bisa dibuka agen.

Agen tidak harus membaca semua dokumen setiap kali. Tetapi kalau jawabannya terasa aneh atau kasusnya sensitif, mereka masih bisa mengecek dari mana informasi itu berasal.

Kasus Schneider Electric yang dipublikasikan Udesk cukup menggambarkan masalah ini. Udesk menjelaskan bahwa staf customer service Schneider menghadapi pertanyaan yang semakin kompleks, sementara knowledge yang dibutuhkan tidak selalu mudah ditemukan. KCS Knowledge Base dan enterprise search dipakai untuk mempercepat pencarian informasi.

Kasusnya memang bukan studi agent assist real time secara khusus. Tetapi problem dasarnya sama. Informasi sebenarnya ada, hanya saja agen kesulitan menemukannya pada saat pelanggan sedang menunggu.

Saran yang terlambat biasanya tidak dipakai

Di demo, agent assist sering terlihat sangat cepat. Kondisi operasional bisa berbeda.

Sistem harus membaca percakapan, mencari knowledge, mungkin mengecek CRM, lalu baru menampilkan rekomendasi. Kalau proses itu terlalu lama, agen biasanya sudah bergerak sendiri.

Di telepon, selisih beberapa detik cukup terasa. Agen tidak mungkin diam terlalu lama hanya karena menunggu AI.

Latency juga tidak selalu datang dari model. Bisa dari transcription, knowledge search, CRM, atau API internal.

Karena itu, saat pilot jangan hanya melihat “response time AI”. Ukur waktu dari percakapan terjadi sampai saran benar-benar muncul di layar agen.

Kalau terlambat terus, masalahnya tetap sama walaupun modelnya bagus.

AI tidak perlu bicara terus

Satu kesalahan yang cukup gampang terjadi adalah membuat sistem terlalu aktif.

Setiap pelanggan bicara, AI memberi saran. Pelanggan ganti topik sedikit, muncul saran baru lagi.

Lama-lama agen berhenti memperhatikan.

Karena itu, confidence threshold cukup berguna. Kalau sistem yakin dengan intent dan sumbernya, tampilkan rekomendasi. Kalau tidak yakin, kadang lebih baik diam atau hanya menunjukkan beberapa artikel untuk dicek agen.

Risiko tiap topik juga beda.

Saran soal jam operasional tidak sama dengan saran soal refund atau perubahan data akun. Untuk kasus yang lebih sensitif, threshold seharusnya lebih ketat.

Feedback agen jangan cuma berupa angka

Accept rate memang mudah dibaca. Reject rate juga mudah dibuat grafiknya.

Tetapi alasan di balik angka itu jauh lebih menarik.

Agen bisa menolak saran karena jawabannya salah. Bisa juga karena bahasanya terlalu formal. Kadang isinya benar, tetapi muncul terlambat. Kadang agen merasa lebih cepat mencari sendiri.

Hal seperti ini tidak selalu kelihatan di dashboard.

Saat pilot, ngobrol dengan agen yang benar-benar memakai sistem. Tanya bagian mana yang membantu dan bagian mana yang malah mengganggu.

Kalau satu rekomendasi hampir selalu diedit dengan pola yang sama, kemungkinan knowledge atau prompt-nya perlu diperbaiki.

Agent assist seharusnya mengurangi kerja kecil yang mengganggu. Kalau agen merasa harus mengurus AI setiap saat, ada yang salah dengan desainnya.

Jangan langsung diuji ke semua tim

Lebih aman mulai dari satu area.

Misalnya pertanyaan produk, retur, atau troubleshooting yang cukup sering muncul.

Rapikan knowledge untuk topik itu lebih dulu. Setelah itu baru aktifkan agent assist ke sebagian agen.

Kelompok lain bisa tetap bekerja seperti biasa. Perbandingan seperti ini lebih gampang dibaca dibanding langsung mengaktifkan fitur ke seluruh customer service.

AHT bisa dilihat untuk mengetahui apakah waktu penanganan turun. FCR juga penting karena jawaban cepat belum tentu menyelesaikan masalah.

Adoption rate membantu melihat apakah agen benar-benar memakai sistem. Tetapi kalau angkanya rendah, jangan langsung menyalahkan pengguna. Bisa jadi sarannya memang belum cukup berguna.

Edit rate juga menarik. Kalau hampir semua jawaban harus banyak diedit, berarti AI belum benar-benar menghemat waktu.

Tidak perlu mengejar angka pemakaian AI

Agen senior mungkin tidak membutuhkan rekomendasi untuk pertanyaan yang sudah mereka hafal. Itu normal.

Agen baru justru sering lebih terbantu karena mereka belum tahu semua SOP atau belum hafal artikel knowledge.

Jadi tujuan pilot tidak perlu dibuat “sebanyak mungkin percakapan memakai AI”.

Lebih masuk akal melihat apakah waktu mencari informasi berkurang, jawaban antaragen lebih konsisten, dan agen tidak perlu terlalu sering pindah aplikasi.

Udesk menghubungkan Agent Assist dengan knowledge base, live chat, ticketing, dan lingkungan contact center. Jadi rekomendasi AI bisa muncul di tempat agen memang sedang bekerja, bukan sebagai tool tambahan yang harus dibuka terpisah. Untuk tim yang ingin mencoba AI secara bertahap tanpa langsung menyerahkan percakapan kepada bot, Udesk bisa dipertimbangkan sebagai salah satu platform pilot karena agen tetap memegang keputusan akhir, sementara AI membantu bagian pekerjaan yang paling sering menyita waktu.

FAQ

Q:Apakah agent assist AI sama dengan chatbot?

A:Tidak. Chatbot berbicara langsung dengan pelanggan, sedangkan agent assist bekerja di belakang agen dan membantu mencari knowledge, membuat draft jawaban, atau memberi saran langkah berikutnya.

Q:Apa KPI yang cocok untuk pilot?

A:AHT, FCR, adoption rate, edit rate, rejection rate, dan waktu pencarian knowledge bisa dibaca bersama. Jangan hanya melihat satu angka.

Q:Apakah saran AI harus langsung dikirim ke pelanggan?

A:Tidak. Agen tetap sebaiknya bisa membaca, mengubah, atau mengabaikan rekomendasi sebelum mengirim jawaban.

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/agent-assist-ai-cara-membantu-agen-menjawab-lebih-cepat-dan-konsisten