Knowledge Base Customer Service: Struktur Konten, Governance, dan Cara Menjaganya Tetap Akurat

Ringkasan artikel：Panduan ini membahas cara membangun knowledge base customer service yang benar-benar berguna untuk pelanggan dan agen. Fokusnya bukan hanya pada jumlah artikel, tetapi pada cara menyusun kategori, metadata, versi, owner, approval, permission, dan jadwal review agar informasi tetap mudah ditemukan dan tidak cepat usang. Artikel juga menjelaskan perbedaan knowledge publik dan internal, pentingnya feedback agen, search log, serta dampak kualitas konten terhadap self-service, agent assist, dan chatbot AI. Cocok untuk Knowledge Manager, tim Customer Support, dan Content Operations yang ingin membuat basis pengetahuan pelanggan lebih rapi, mudah dirawat, dan tetap dipercaya saat digunakan dalam operasional sehari-hari.

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.

Knowledge base customer service biasanya dibuat karena tim sudah capek menjawab hal yang sama. Cara retur bagaimana, kenapa pembayaran belum masuk, paket sudah sampai mana. Awalnya solusi ini terasa sederhana, kumpulkan semua jawaban lalu taruh di satu tempat. Setelah beberapa bulan, baru kelihatan masalahnya. Artikel bertambah terus, ada dua panduan untuk topik yang sama, ada informasi yang sudah berubah, dan agen tetap bertanya di grup karena mereka tidak yakin artikel mana yang masih benar. Jadi masalah knowledge base sebenarnya bukan hanya soal punya atau tidak punya software knowledge base.

Kategori jangan dibuat seperti struktur kantor

Ini cukup sering terjadi. Karena Finance mengurus pembayaran, dibuat folder Finance. Karena tim Operations menangani pengiriman, dibuat folder Operations.

Bagi orang internal mungkin masuk akal. Pelanggan tidak berpikir seperti itu.

Mereka biasanya mencari “paket belum datang”, “cara refund”, atau “akun tidak bisa login”. Jadi basis pengetahuan pelanggan lebih enak kalau dibagi mengikuti masalah yang mereka alami. Misalnya Pesanan, Pengiriman, Pembayaran, Retur, dan Akun.

Untuk agen, kategorinya boleh lebih teknis. Ada SOP, troubleshooting, produk, atau eskalasi. Tapi tidak perlu terlalu banyak subfolder. Kalau mencari satu artikel saja sudah harus buka folder sampai empat tingkat, biasanya agen lebih memilih bertanya ke teman.

Tag atau metadata bisa membantu. Artikel tentang refund, misalnya, bisa diberi tag produk tertentu, negara, bahasa, dan tanggal review. Jadi tidak semuanya harus dibuat menjadi folder baru.

Artikel untuk pelanggan dan agen memang sebaiknya beda

Ambil contoh masalah refund.

Pelanggan biasanya ingin tahu tiga hal. Bisa refund atau tidak, caranya bagaimana, dan berapa lama prosesnya.

Agen butuh lebih banyak. Ia perlu tahu syarat yang harus dicek, kasus apa yang harus meminta approval, dan kalau ada kondisi aneh harus diteruskan ke siapa.

Kalau dua kebutuhan ini dimasukkan ke satu artikel, hasilnya sering tanggung. Terlalu rumit untuk pelanggan, tetapi masih kurang lengkap bagi agen.

Lebih aman memang memisahkan knowledge publik dan internal. Tidak harus punya dua sistem. Yang penting permission-nya jelas.

Ini juga penting kalau artikel nantinya dipakai chatbot. Jangan sampai bot pelanggan mengambil bagian SOP internal hanya karena artikelnya ada di database yang sama.

Artikel tidak perlu terdengar seperti dokumen hukum

Knowledge base sering ditulis terlalu formal.

Judulnya “Prosedur Pelaksanaan Perubahan Alamat Pengiriman Setelah Pesanan Dikonfirmasi”. Padahal agen mungkin mencari “ganti alamat”.

Bahasanya juga kadang panjang sekali sebelum sampai ke jawaban.

Kalau orang mencari cara mengganti alamat, kasih tahu dulu apakah bisa atau tidak. Setelah itu baru jelaskan langkahnya.

Untuk artikel agen, tulis apa yang benar-benar mereka butuhkan saat bekerja. Contohnya, cek nomor order, lihat status shipment, kalau sudah masuk proses tertentu jangan ubah manual, lalu eskalasi ke tim terkait.

Tidak harus semuanya sangat rapi. Yang lebih penting, agen tidak perlu menerjemahkan isi artikel di kepala mereka sendiri sebelum menggunakannya.

Masalah paling bikin pusing biasanya artikel lama

Artikel baru gampang dibuat. Artikel lama yang sudah tidak berlaku justru sering dibiarkan.

Misalnya aturan retur berubah bulan Januari. Tim membuat artikel baru, tetapi artikel lama tidak dihapus karena “siapa tahu masih diperlukan”. Akhirnya kedua artikel muncul di search.

Kalau ini terjadi terus, agen mulai tidak percaya dengan hasil pencarian.

Setiap kelompok artikel perlu punya orang atau tim yang bertanggung jawab. Bukan berarti mereka harus menulis semua konten. Setidaknya kalau kebijakan berubah, ada orang yang tahu artikel mana yang harus ikut diperbarui.

Untuk harga dan promo, masa berlaku sebaiknya jelas. Artikel lama boleh disimpan sebagai arsip, tetapi jangan tetap muncul di hasil pencarian harian.

Versi juga tidak perlu dibuat rumit. Yang penting agen tidak melihat tiga artikel yang judulnya hampir sama lalu harus menebak sendiri.

Agen biasanya yang pertama tahu ada artikel bermasalah

Kalau artikel knowledge tidak enak digunakan, agen cepat tahu.

Ada artikel yang sebenarnya benar, tetapi terlalu panjang. Ada yang jawabannya kurang satu langkah. Ada juga yang sudah lama, tetapi masih muncul paling atas saat dicari.

Karena itu, feedback dari agen jangan dianggap tambahan saja.

Tidak perlu membuat form panjang. Tombol seperti “berguna”, “kurang lengkap”, atau “sudah tidak berlaku” sudah cukup. Setelah itu Knowledge Manager tinggal melihat artikel mana yang sering mendapat masalah.

Search log juga lumayan berguna. Kalau orang terus mencari “refund gagal” tetapi tidak pernah klik hasil yang ada, mungkin istilah di artikel tidak cocok dengan bahasa yang mereka gunakan.

Kadang masalahnya bukan tidak punya konten. Kontennya ada, cuma sulit ditemukan.

Kasus Schneider Electric cukup dekat dengan masalah ini

Udesk pernah mempublikasikan studi kasus Schneider Electric. Salah satu masalah yang disebut adalah pertanyaan pelanggan makin kompleks sementara staf customer service tidak selalu mudah menemukan knowledge yang mereka perlukan.

Udesk menggunakan KCS Knowledge Base dan enterprise search untuk membantu pencarian informasi.

Saya rasa bagian yang paling relevan bukan soal nama produknya. Masalah seperti ini memang sering terjadi ketika perusahaan sudah punya banyak dokumen, tetapi knowledge tersebar dan tidak praktis dipakai saat agen sedang bicara dengan pelanggan.

AI membuat masalah knowledge lama lebih mudah kelihatan

Dulu, artikel yang sudah usang mungkin hanya dipakai sesekali oleh agen.

Sekarang artikel yang sama bisa dipakai chatbot, agent assist, dan portal self-service sekaligus.

Kalau informasinya salah, kesalahannya ikut dipakai di beberapa tempat.

Jadi sebelum bicara soal model AI atau prompt, ada pekerjaan yang jauh lebih biasa. Cek artikel lama. Pastikan owner-nya jelas. Lihat apakah permission sudah benar. Jangan biarkan dua versi kebijakan aktif bersamaan.

Banyak masalah jawaban AI sebenarnya bukan karena AI “tidak pintar”. Sumber yang diberikan kepadanya memang tidak beres.

Tidak perlu audit semua artikel setiap minggu

Knowledge base yang sudah besar bisa punya ratusan atau ribuan artikel. Tidak realistis kalau semuanya diperiksa terus-menerus.

Prioritaskan saja yang paling berisiko.

Artikel harga, promo, refund, garansi, atau kebijakan pelanggan biasanya perlu diperiksa lebih sering. Artikel panduan dasar yang hampir tidak pernah berubah bisa ditinjau lebih jarang.

Lihat juga artikel yang sering dipakai chatbot atau agent assist. Kalau artikel seperti ini salah, dampaknya lebih luas dibanding satu artikel internal yang jarang dibuka.

Cara lain yang cukup sederhana adalah melihat tiket masuk. Kalau perusahaan sudah punya artikel tentang satu topik tetapi pertanyaan yang sama tetap masuk terus, coba baca artikelnya lagi. Mungkin pelanggan memang tidak menemukan jawabannya di sana.

Pada akhirnya, knowledge base tidak perlu terlihat sangat canggih. Yang penting orang masih percaya dengan isi yang mereka temukan. Udesk menyediakan AI Knowledge Base yang dapat digunakan untuk self-service, pencarian agen, agent assist, dan chatbot, jadi knowledge yang sama bisa dipakai di beberapa bagian layanan tanpa harus dikelola ulang di banyak tempat. Untuk tim yang mulai kesulitan menjaga versi artikel, permission, dan pembaruan manual, Udesk bisa dipertimbangkan sebagai salah satu cara membuat knowledge lebih mudah dirawat sebelum jumlah kontennya makin besar.

FAQ

Q:Apa bedanya knowledge publik dan internal?

A:Knowledge publik memang dibuat untuk pelanggan. Knowledge internal bisa berisi SOP, langkah verifikasi, aturan eskalasi, dan informasi yang tidak perlu dilihat pelanggan.

Q:Siapa yang sebaiknya mengurus artikel?

A:Tim yang paling memahami isi artikelnya. Tidak harus penulis artikel, yang penting ada orang yang bertanggung jawab saat informasinya berubah.

Q:Apakah semua artikel harus sering diperiksa?

A:Tidak. Prioritaskan konten yang cepat berubah atau berdampak langsung ke pelanggan, misalnya harga, promo, retur, dan garansi.

Permudah jawaban mandiri pelanggan dan kurangi beban tim dengan Basis Pengetahuan Udesk! Coba gratis sekarang dan rasakan efisiensi penanganan pertanyaan yang berbeda.

Artikel ini merupakan karya asli Udesk. Jika akan diterbitkan ulang, wajib selalu mencantumkan sumber aslinya：https://id.udeskglobal.com/blog/knowledge-base-customer-service-struktur-konten-governance-dan-cara-menjaganya-tetap-akurat