Studi Kasus: Copilot Perbankan Menurunkan Waktu Layanan 38%
Bagaimana sebuah copilot berbasis pengetahuan memangkas waktu penanganan di cabang bank sebesar 38%. Studi kasus ini membedah arsitektur, hambatan, dan pelajarannya.
N
Nyuhani PrasastiApril 11, 2026
Case StudyStudi KasusPerbankan
Di sebuah cabang bank menengah di kota besar Indonesia, seorang petugas layanan nasabah menghadapi antrean yang tak kunjung surut. Seorang nasabah menanyakan syarat pembukaan deposito valas dengan ketentuan khusus, dan petugas itu — yang baru enam bulan bekerja — harus membuka tiga aplikasi internal, mencari di portal kebijakan yang antarmukanya berasal dari era yang lampau, lalu menelepon kantor pusat untuk memastikan. Lima belas menit berlalu. Antrean memanjang. Nasabah berikutnya sudah menghela napas. Pemandangan ini berulang ratusan kali setiap hari di puluhan cabang, dan setiap menit yang terbuang adalah biaya yang nyata: waktu staf, kepuasan nasabah yang menurun, dan kapasitas layanan yang tergerus.
Want to run this playbook with us?
A 30-minute scoping call. We listen, ask three questions, tell you if we can help.
Artikel ini membedah bagaimana sebuah copilot berbasis pengetahuan membantu memangkas waktu penanganan di cabang sebesar 38%. Sebagai catatan, studi kasus ini bersifat komposit dan ilustratif — merupakan gabungan dari beberapa pengalaman penerapan yang dianonimkan, bukan satu klien tunggal yang dapat diidentifikasi. Angka dan dinamika yang dipaparkan mencerminkan pola nyata yang berulang di sektor perbankan, disajikan untuk pembelajaran tanpa mengungkap identitas pihak mana pun.
Konteks dan Masalah
Bank yang kita sebut "sebuah bank menengah" ini memiliki jaringan cabang yang luas dengan ribuan petugas layanan dan teller. Tantangannya klasik namun mahal.
Pertama, pengetahuan tersebar dan sulit diakses. Kebijakan produk, prosedur operasi standar, ketentuan regulasi, dan FAQ internal tersimpan di berbagai sistem: portal intranet lama, dokumen PDF di server bersama, lampiran email, dan — yang paling problematik — di kepala segelintir staf senior. Ketika staf senior cuti atau pindah, pengetahuan itu ikut menghilang.
Kedua, variasi kualitas layanan tinggi. Petugas berpengalaman bisa menjawab pertanyaan rumit dalam hitungan detik; petugas baru butuh berlipat-lipat lebih lama dan kadang memberi jawaban tidak akurat. Inkonsistensi ini berisiko, terutama untuk produk dengan ketentuan kompleks atau implikasi kepatuhan.
Ketiga, waktu penanganan (handling time) tinggi. Rata-rata waktu yang dibutuhkan untuk menyelesaikan satu interaksi nasabah yang melibatkan pertanyaan non-rutin jauh melampaui target internal. Ini membatasi jumlah nasabah yang bisa dilayani, memperpanjang antrean, dan menekan skor kepuasan.
Masalah sebenarnya bukan staf yang lambat, melainkan pengetahuan yang terkubur. Petugas menghabiskan lebih banyak waktu mencari jawaban daripada melayani nasabah.
Manajemen sempat mempertimbangkan solusi konvensional: pelatihan lebih intensif, penambahan staf, atau memperbarui portal pengetahuan. Tetapi pelatihan tidak menyelesaikan masalah akses real-time, penambahan staf mahal dan tidak skalabel, dan portal yang lebih baik pun tetap menuntut petugas tahu di mana dan bagaimana mencari. Yang dibutuhkan adalah cara membawa pengetahuan langsung ke titik layanan, saat dibutuhkan, dalam bahasa yang bisa langsung dipakai.
Pendekatan Solusi
Solusinya berupa copilot berbasis RAG (retrieval-augmented generation) — asisten yang bisa ditanyai dalam bahasa sehari-hari oleh petugas, lalu menjawab dengan grounding ke dokumen kebijakan resmi bank, lengkap dengan rujukan sumber.
Arsitektur inti
Fondasinya adalah pipeline RAG yang disiplin. Dokumen kebijakan, SOP, ketentuan produk, dan FAQ dikumpulkan, dibersihkan, dipecah menjadi potongan (chunk) yang bermakna, lalu diindeks ke vector database. Ketika petugas mengajukan pertanyaan, sistem mengambil potongan paling relevan dan menyusun jawaban menggunakan LLM yang dibatasi hanya menjawab berdasarkan dokumen yang diambil — bukan dari "pengetahuan umum" model yang berisiko salah untuk konteks spesifik bank ini.
Setiap jawaban menyertakan sitasi ke dokumen sumber. Ini bukan sekadar fitur kenyamanan, melainkan keharusan: petugas perbankan tidak boleh mengandalkan jawaban yang tidak bisa diverifikasi, dan auditor perlu jejak yang jelas. Jika copilot tidak menemukan dasar yang memadai dalam dokumen, ia dirancang untuk mengatakan "informasi tidak ditemukan, silakan hubungi unit terkait" alih-alih mengarang — perilaku abstain yang krusial untuk kepercayaan.
Integrasi ke alur kerja
Copilot tidak dibangun sebagai aplikasi terpisah yang harus dibuka di tab lain. Ia disematkan ke antarmuka kerja petugas, sehingga pertanyaan bisa diajukan tanpa berpindah konteks. Detail kecil ini berdampak besar pada adopsi — alat yang menambah langkah cenderung diabaikan, alat yang menghilangkan langkah cepat dirangkul.
Evaluasi sebelum produksi
Sebelum diluncurkan, sistem diuji dengan golden dataset: ratusan pertanyaan nyata yang sering diajukan, dengan jawaban benar yang telah divalidasi unit kepatuhan dan ahli produk. Setiap iterasi sistem diukur terhadap dataset ini untuk faithfulness (apakah jawaban setia pada sumber), relevansi, dan kelengkapan. Tidak ada peluncuran sebelum akurasi melewati ambang yang disepakati bersama unit risiko.
Hambatan yang Dihadapi
Perjalanan menuju produksi tidak mulus. Justru hambatan-hambatan inilah yang paling instruktif.
Kepatuhan dan tata kelola. Sektor perbankan diawasi ketat. Unit kepatuhan dan manajemen risiko awalnya skeptis — wajar — terhadap sistem AI yang bisa "mengarang". Kekhawatiran utamanya: bagaimana jika copilot memberi jawaban salah yang menyesatkan nasabah, atau membocorkan informasi yang tidak seharusnya? Menjawab kekhawatiran ini menuntut desain yang menempatkan kepatuhan di pusat: jawaban selalu tergrounding dan tersitasi, perilaku abstain ketika ragu, audit trail penuh atas setiap pertanyaan dan jawaban, serta kontrol akses yang memastikan petugas hanya melihat informasi yang berhak mereka akses. Prinsip-prinsip ekspektasi OJK terkait manajemen risiko model dan jejak audit menjadi panduan, bukan halangan.
Kualitas dan kebersihan dokumen. Hambatan teknis terbesar bukan model, melainkan data. Dokumen kebijakan ternyata penuh versi ganda, ketentuan kedaluwarsa yang belum dicabut, dan format tidak konsisten. Copilot yang dilatih pada sumber kotor menghasilkan jawaban kotor. Sebagian besar usaha awal tersedot untuk membersihkan, mendeduplikasi, dan menetapkan kepemilikan atas dokumen — siapa yang bertanggung jawab menjaga setiap kebijakan tetap mutakhir. Ini menegaskan pelajaran lama: knowledge base yang rapi adalah prasyarat, bukan hasil sampingan.
Privasi data. Dengan UU PDP No. 27/2022 dan kerahasiaan perbankan, data nasabah tidak boleh sembarangan mengalir ke layanan AI. Arsitektur dirancang agar copilot menjawab pertanyaan tentang kebijakan dan prosedur — bukan mengakses data pribadi nasabah individual kecuali melalui kontrol yang sangat ketat. Pemisahan ini menjaga kepatuhan sekaligus menyederhanakan permukaan risiko.
Kepercayaan pengguna. Petugas senior awalnya curiga alat ini akan menggantikan keahlian mereka, sementara petugas baru kadang terlalu mempercayai jawaban tanpa verifikasi. Keduanya berbahaya. Solusinya gabungan: komunikasi yang menempatkan copilot sebagai pembantu (bukan pengganti), pelatihan singkat tentang cara membaca sitasi dan kapan tetap memverifikasi, serta desain yang selalu menampilkan sumber agar petugas terbiasa memeriksa.
Hasil
Setelah peluncuran bertahap — dimulai dari sekelompok cabang percontohan sebelum diperluas — dampaknya terukur jelas.
Waktu penanganan turun 38% untuk interaksi yang melibatkan pertanyaan non-rutin. Petugas yang sebelumnya membuka beberapa sistem dan menelepon kantor pusat kini mendapat jawaban tergrounding dalam hitungan detik. Pengurangan ini langsung menerjemahkan menjadi antrean yang lebih pendek dan kapasitas layanan yang lebih besar tanpa menambah staf.
Selain angka utama itu, beberapa dampak turunan muncul:
Konsistensi jawaban meningkat. Petugas baru dan senior kini memberi jawaban yang seragam dan akurat, mengurangi risiko misinformasi dan keluhan.
Waktu adaptasi staf baru memendek. Petugas baru menjadi produktif lebih cepat karena tidak perlu menghafal seluruh kebijakan; pengetahuan tersedia saat dibutuhkan.
Beban kantor pusat berkurang. Telepon eskalasi untuk pertanyaan yang sebenarnya terjawab di dokumen menurun, membebaskan tim pusat untuk kasus yang benar-benar kompleks.
Kepuasan nasabah membaik seiring layanan yang lebih cepat dan akurat.
Penting digarisbawahi: angka 38% bukan hasil dari model yang ajaib, melainkan dari kombinasi knowledge base yang dibersihkan, RAG yang disiplin, integrasi ke alur kerja, dan adopsi yang dikelola dengan baik. Hilangkan salah satu komponen, dan hasilnya akan jauh lebih kecil.
Pembelajaran
Beberapa pelajaran dari studi kasus komposit ini berlaku jauh melampaui satu bank.
Data mengalahkan model. Mayoritas usaha dan nilai berasal dari membersihkan serta menata pengetahuan, bukan dari memilih LLM tercanggih. Organisasi yang berharap membeli model pintar lalu menyelesaikan masalah akan kecewa.
Kepatuhan adalah fitur, bukan penghalang. Dengan menempatkan grounding, sitasi, abstain, dan audit trail di inti desain sejak awal, kepatuhan berubah dari hambatan menjadi pembeda yang membangun kepercayaan unit risiko dan nasabah.
Adopsi ditentukan oleh integrasi dan manajemen perubahan. Sistem terbaik secara teknis pun gagal jika menambah gesekan atau jika staf tidak dilibatkan. Menyematkan alat ke alur kerja dan mengkomunikasikan perannya secara jujur menentukan apakah teknologi benar-benar dipakai.
Mulai kecil, buktikan, lalu skalakan. Peluncuran bertahap dari cabang percontohan memungkinkan tim belajar, memperbaiki, dan membangun bukti sebelum menyebarkannya ke seluruh jaringan — mengurangi risiko dan memenangkan dukungan internal.
Abstain lebih berharga daripada jawaban percaya diri yang salah. Di perbankan, jawaban salah lebih merugikan daripada tidak ada jawaban. Merancang sistem yang tahu kapan mengatakan "saya tidak yakin" adalah keputusan kepercayaan yang krusial.
Mempertahankan Sistem Setelah Peluncuran
Banyak studi kasus berhenti di angka kemenangan, seolah peluncuran adalah akhir cerita. Realitanya, mempertahankan dampak 38% itu sama menantangnya dengan mencapainya. Beberapa praktik menjaga sistem tetap berharga seiring waktu.
Pemeliharaan knowledge base berkelanjutan. Kebijakan bank berubah — suku bunga, ketentuan produk, regulasi baru dari OJK. Jika dokumen sumber tidak diperbarui, copilot mulai memberi jawaban usang yang justru berbahaya. Solusinya adalah menetapkan kepemilikan yang jelas: setiap kebijakan punya penanggung jawab yang wajib memutakhirkannya, dan ada proses yang memastikan perubahan kebijakan langsung mengalir ke indeks copilot. Tanpa disiplin ini, akurasi yang susah payah dibangun akan tergerus diam-diam.
Observability dan evaluasi online. Sistem memantau pertanyaan yang sering tidak terjawab, jawaban yang ditandai petugas sebagai tidak membantu, dan pola di mana copilot sering abstain. Sinyal ini mengungkap celah dalam knowledge base — pertanyaan yang sering muncul tetapi tidak ada dokumennya menjadi prioritas untuk diisi. Loop umpan balik ini mengubah copilot dari sistem statis menjadi kapabilitas yang terus menajam.
Tinjauan kepatuhan berkala. Unit risiko meninjau sampel interaksi secara rutin untuk memastikan jawaban tetap akurat dan patuh. Ini bukan sekadar formalitas; ia menjaga kepercayaan yang menjadi fondasi seluruh sistem dan memenuhi ekspektasi regulator atas pengawasan berkelanjutan terhadap sistem AI.
Membaca Angka dengan Jujur
Angka 38% mengesankan, tetapi praktisi yang baik memperlakukan klaim semacam ini dengan kehati-hatian. Beberapa catatan kejujuran yang penting.
Pertama, dampak bervariasi per jenis interaksi. Penurunan terbesar terjadi pada pertanyaan non-rutin yang kompleks; interaksi yang sudah sederhana tidak banyak berubah. Angka agregat menyembunyikan distribusi ini, jadi mengukur dampak per segmen memberi gambaran lebih jujur.
Kedua, ada faktor lain yang berkontribusi di luar copilot — perbaikan proses, pelatihan yang menyertai peluncuran, dan efek Hawthorne di mana staf bekerja lebih cermat ketika tahu sedang diamati. Atribusi yang jujur mengakui copilot sebagai kontributor utama, bukan satu-satunya penyebab.
Ketiga, dampak nyata butuh waktu untuk matang. Lonjakan awal sering memudar sebelum stabil di level yang berkelanjutan setelah staf benar-benar terbiasa dan knowledge base dimatangkan. Mengukur terlalu dini bisa melebih-lebihkan atau justru meremehkan dampak sejati.
Kejujuran semacam ini bukan kelemahan — justru ia yang membedakan klaim yang kredibel di hadapan direksi dan auditor dari janji pemasaran yang rapuh ketika diteliti.
Wujudkan Hasil Serupa Bersama Sainskerta Solusi Nusantara
Kisah komposit ini menggambarkan pola yang konsisten: copilot berbasis pengetahuan dapat memberi dampak operasional yang nyata dan terukur ketika dibangun dengan fondasi data yang bersih, desain yang menempatkan kepatuhan di pusat, dan adopsi yang dikelola dengan saksama. Penurunan waktu layanan 38% bukan keajaiban teknologi, melainkan hasil rekayasa yang disiplin di setiap tahap.
Sainskerta Solusi Nusantara mendampingi institusi keuangan dan enterprise Indonesia membangun copilot serta sistem RAG yang patuh OJK dan UU PDP, dari fase strategi dan desain hingga pembangunan dan operasi berkelanjutan. Jika organisasi Anda memikul beban pengetahuan yang terkubur dan waktu layanan yang tinggi, jadwalkan sesi konsultasi dengan tim kami melalui halaman Kontak. Kami akan membantu menilai kesiapan knowledge base Anda, merancang arsitektur yang aman, dan menyusun peta jalan dari pilot ke produksi — sehingga dampak yang Anda baca di studi kasus ini bisa menjadi hasil nyata di organisasi Anda sendiri.
Studi Kasus: Copilot Perbankan Menurunkan Waktu Layanan 38% — Sainskerta Blog · Sainskerta
