First Call Resolution: Rumus FCR dan Cara Meningkatkannya di Contact Center

Ringkasan artikel：Panduan ini membahas first call resolution dan cara menghitung FCR dengan aturan yang jelas, termasuk eligible contact, transfer, reopen, dan denominator. Artikel juga menjelaskan perbedaan first call resolution dan resolusi kontak pertama dalam lingkungan omnichannel. Fokus utamanya adalah mencari penyebab FCR rendah dari routing, akses knowledge, keterbatasan wewenang agen, integrasi data, dan repeat contact. Contoh dashboard mingguan disertakan untuk membantu contact center manager, QA, dan CX analyst membaca perubahan FCR bersama reopen rate, transfer rate, CSAT, serta kualitas penyelesaian. Tujuannya bukan sekadar menaikkan angka, tetapi mengurangi alasan pelanggan harus menghubungi perusahaan kembali.

Oleh Siti Ayu

Siti Ayu, Manajer Keberhasilan Pelanggan di Udesk. Ia ahli dalam penerapan layanan pelanggan, mendukung merek manufaktur, ritel dan global untuk mengoptimalkan operasi dukungan serta CSAT.

First call resolution sering terlihat seperti metrik yang mudah: pelanggan menelepon, masalah selesai, lalu dihitung berhasil. Begitu dipakai di operasi nyata, definisinya mulai rumit. Apakah transfer masih dihitung? Bagaimana kalau pelanggan menelepon lagi besok untuk masalah yang sama? Karena itu, sebelum bicara cara meningkatkan FCR, tim sebaiknya sepakat dulu tentang aturan hitungnya.

First call dan first contact resolution tidak persis sama

Istilah first call resolution biasanya dipakai untuk voice atau call center. Artinya, kebutuhan pelanggan selesai dalam panggilan pertama tanpa harus menelepon lagi untuk masalah yang sama.

First contact resolution lebih luas. Pelanggan bisa memulai dari WhatsApp, email, live chat, telepon, atau kanal lain. Selama masalah selesai pada kontak pertama sesuai aturan perusahaan, interaksi tersebut dapat dihitung sebagai resolusi kontak pertama.

Perbedaannya penting kalau perusahaan sudah omnichannel.

Pelanggan mungkin bertanya lewat chat, kemudian menelepon dua jam kemudian karena masalah belum selesai. Dari sisi call center, panggilan tersebut mungkin kelihatan seperti first call. Dari sisi customer journey, sebenarnya itu sudah kontak kedua.

Jadi jangan mencampur metrik channel dengan metrik customer journey tanpa definisi yang jelas.

Rumus FCR sederhana, denominator-nya yang sering bikin bingung

Rumus dasarnya:

FCR = jumlah kontak yang selesai pada kontak pertama ÷ jumlah kontak yang memenuhi syarat × 100%

Misalnya dalam satu minggu ada 1.000 kontak yang memang masuk perhitungan. Dari jumlah itu, 720 selesai tanpa kontak ulang sesuai periode yang ditetapkan. FCR berarti 72%.

Yang perlu diperhatikan justru angka 1.000 tadi.

Tidak semua interaction harus masuk denominator. Spam, salah sambung, panggilan putus sebelum agen sempat melayani, atau kontak yang memang bukan permintaan layanan mungkin perlu dikeluarkan.

Jangan mengubah aturan denominator dari minggu ke minggu. Kalau bulan lalu disconnected call dikeluarkan tetapi bulan ini ikut dihitung, perubahan FCR tidak lagi mudah dibaca.

Untuk operasi omnichannel, lebih aman mempunyai dokumen pendek yang menjelaskan apa yang disebut eligible contact, kapan dianggap resolved, dan kondisi apa yang membatalkan FCR.

Transfer perlu punya aturan sendiri

Transfer adalah salah satu bagian yang sering memicu perdebatan.

Misalnya pelanggan menelepon general customer service, lalu agen mentransfernya ke tim teknis. Tim teknis menyelesaikan masalah dalam panggilan yang sama.

Apakah itu FCR?

Bisa iya atau tidak, tergantung apa yang ingin diukur.

Kalau perusahaan mengukur pengalaman pelanggan pada level contact center, kasus tersebut masih bisa dianggap selesai dalam satu kontak karena pelanggan tidak perlu menelepon kembali.

Tetapi kalau FCR dipakai untuk menilai kemampuan queue atau agen tertentu, transfer mungkin perlu dicatat sebagai non-FCR pada level agen pertama.

Karena itu, jangan mencari satu definisi “paling benar”. Tentukan level pengukurannya.

Yang tidak bagus adalah supervisor A menghitung transfer sebagai berhasil sementara supervisor B menganggapnya gagal.

Transfer rate sendiri tetap perlu dilihat. FCR tinggi dengan transfer rate yang sangat tinggi bisa berarti masalah selesai, tetapi routing awal belum tepat.

Tiket yang dibuka kembali bisa mengubah FCR

Kasus terlihat selesai hari Senin. Selasa pelanggan kembali karena solusi pertama ternyata tidak bekerja.

Kalau laporan Senin sudah menghitung kasus tersebut sebagai FCR dan tidak pernah dikoreksi, angka akan terlihat terlalu bagus.

Tim perlu menentukan reopen window.

Misalnya masalah yang muncul kembali dalam 48 atau 72 jam dan masih berkaitan dengan topik yang sama dianggap bukan first contact resolution.

Tidak semua bisnis perlu memakai window yang sama. Troubleshooting perangkat mungkin membutuhkan waktu lebih lama untuk memastikan solusi berhasil. Pertanyaan alamat cabang tidak perlu menunggu tiga hari.

Yang penting, aturan reopen dibuat sebelum dashboard dipakai sebagai KPI.

Periksa juga alasan reopen. Pelanggan kembali karena masalah yang sama berbeda dengan pelanggan yang datang lagi dengan pertanyaan baru.

Routing sering menjadi masalah pertama

Cara meningkatkan FCR tidak selalu dimulai dari training agen.

Kadang pelanggan memang masuk ke orang yang salah.

Pertanyaan teknis masuk ke general agent. Agen pertama hanya mengumpulkan informasi lalu meneruskan kasus ke teknisi. Pelanggan harus menjelaskan ulang. Waktu habis, transfer bertambah, dan peluang menyelesaikan kasus pada kontak pertama turun.

Skill-based routing dapat membantu mengarahkan percakapan berdasarkan produk, bahasa, jenis masalah, atau keahlian agen.

Tidak perlu membuat puluhan rule sekaligus.

Ambil beberapa kategori yang memang sering ditransfer. Kalau 35% pertanyaan billing selalu berpindah dari queue umum ke finance support, itu tempat yang cukup jelas untuk mulai memperbaiki routing.

Udesk, misalnya, menyediakan intelligent routing berdasarkan keahlian dan workflow ticketing dengan assignment berdasarkan skill maupun workload.

Agen harus bisa menemukan jawaban saat pelanggan masih menunggu

Routing yang tepat belum cukup kalau agen tetap kesulitan mencari informasi.

Bayangkan pelanggan bertanya tentang garansi produk lama. Agen membuka folder internal, mencari file PDF, lalu bertanya ke rekan kerja apakah aturan tersebut masih berlaku.

Akhirnya pelanggan diminta menunggu callback.

Masalah seperti ini sering kelihatan sebagai “agen kurang cepat”, padahal akar masalahnya akses knowledge.

Knowledge base yang berguna bukan sekadar tempat menyimpan banyak artikel. Jawabannya harus mudah ditemukan dan masih berlaku.

Kasus resmi Udesk untuk Schneider Electric cukup relevan di sini. Udesk menyebut salah satu tantangan Schneider adalah pertanyaan pelanggan yang semakin kompleks sementara knowledge yang tersedia bagi staf customer service masih terbatas. Dalam solusi yang diterapkan, Schneider menggunakan KCS Knowledge Base dan enterprise search untuk membantu agen memberikan jawaban yang lebih tepat dan mendalam.

Halaman tersebut tidak mempublikasikan angka FCR Schneider, jadi kasus ini tidak bisa dipakai untuk mengatakan FCR mereka naik sekian persen. Yang relevan adalah hubungannya dengan salah satu syarat FCR: agen harus bisa menemukan jawaban ketika pelanggan masih berada dalam interaksi yang sama.

Kadang agen tahu jawabannya, tetapi tidak punya wewenang

Ini bottleneck lain yang cukup sering terjadi.

Agen tahu refund boleh diberikan, tetapi semua refund harus disetujui supervisor. Agen tahu alamat pelanggan harus diperbaiki, tetapi hanya back-office yang boleh mengubah data.

Akhirnya tiket selalu menjadi follow-up.

Tentu tidak semua wewenang bisa diberikan ke frontline. Ada risiko fraud dan kontrol internal.

Tapi perusahaan bisa melihat kasus mana yang sebenarnya aman untuk diputuskan agen dalam batas tertentu.

Contohnya, refund di bawah nominal tertentu bisa mendapat rule yang lebih sederhana. Perubahan informasi non-sensitif mungkin tidak perlu approval dua level.

FCR kadang naik bukan karena agen menjadi lebih pintar, melainkan karena mereka akhirnya diizinkan menyelesaikan masalah.

Integrasi data juga menentukan apakah pelanggan harus menunggu

Kalau agen harus membuka lima aplikasi, first contact resolution akan sulit naik.

Pelanggan menanyakan status order. Agen membuka CRM untuk profil, OMS untuk pesanan, sistem pembayaran untuk transaksi, lalu sistem logistik untuk tracking.

Kalau satu aplikasi lambat atau agen tidak punya akses, pelanggan diminta menunggu.

Tidak semua data harus dipindahkan ke satu sistem. Yang lebih penting adalah informasi yang dibutuhkan saat percakapan bisa muncul di workspace agen.

Udesk Omnichannel, misalnya, mendukung sinkronisasi dengan sistem bisnis seperti ERP, OMS, WMS, dan BI.

Untuk evaluasi internal, lihat kasus non-FCR dan tanyakan pertanyaan sederhana: sebenarnya agen gagal menyelesaikan masalah karena tidak tahu jawabannya, tidak punya data, atau tidak punya kewenangan?

Tiga penyebab itu membutuhkan perbaikan yang berbeda.

Contoh dashboard FCR mingguan

Dashboard tidak perlu terlalu ramai. Berikut contoh sederhana. Angkanya hanya ilustrasi, bukan benchmark industri.

Tambahkan lima atau sepuluh kategori dengan FCR terendah.

Misalnya billing punya FCR 82%, sedangkan technical troubleshooting hanya 51%. Informasi ini jauh lebih berguna daripada hanya melihat rata-rata contact center 74%.

Tim QA kemudian bisa mengambil sampel dari kategori 51% tadi dan membaca percakapannya.

Cari akar masalah dari kontak yang gagal selesai

Jangan langsung memberi coaching ke agen setiap kali FCR rendah.

Ambil 50 atau 100 kasus non-FCR. Kelompokkan alasannya.

Berapa yang salah routing? Berapa yang tidak menemukan knowledge? Berapa yang menunggu sistem lain? Berapa yang memerlukan approval? Berapa yang memang secara alami tidak mungkin selesai dalam satu kontak?

Dari situ baru terlihat apa yang sebenarnya perlu diperbaiki.

Kalau penyebab terbesar adalah akses data, training komunikasi tidak akan banyak membantu.

Kalau masalahnya artikel knowledge yang usang, menambah headcount juga tidak menyelesaikannya.

Dan kalau jenis kasus memang membutuhkan investigasi beberapa hari, jangan memaksa FCR tinggi dengan menutup tiket terlalu cepat.

Jangan mengejar FCR sampai pelanggan dirugikan

Angka yang terlalu dijadikan target bisa menghasilkan perilaku aneh.

Agen mungkin enggan transfer karena takut FCR turun. Tiket ditutup walaupun masalah belum benar-benar selesai. Pelanggan mendapat jawaban cepat, tapi harus kembali keesokan hari.

Karena itu, baca FCR bersama reopen rate, repeat contact, transfer rate, CSAT, dan bila perlu quality score.

FCR tinggi baru menarik kalau kualitasnya juga tetap baik.

Untuk contact center yang ingin memperbaiki resolusi kontak pertama dari sisi routing, knowledge, ticketing, integrasi data, dan pekerjaan agen, Udesk dapat dipertimbangkan karena platformnya menggabungkan omnichannel workspace, intelligent routing, Ticket Management, AI Knowledge Base, Agent Copilot, dan integrasi dengan sistem bisnis dalam lingkungan layanan yang sama. Nilainya bukan sekadar membuat angka FCR terlihat lebih tinggi, tetapi mengurangi alasan-alasan kecil yang membuat pelanggan harus menghubungi perusahaan untuk kedua kalinya.

FAQ

Q:Apa rumus first call resolution?

A:FCR dihitung dengan membagi jumlah kontak eligible yang selesai pada kontak pertama dengan seluruh eligible first contacts, lalu dikalikan 100%. Aturan eligible contact harus konsisten.

Q:Apakah transfer otomatis membuat FCR gagal?

A:Tidak selalu. Kalau yang diukur adalah contact center secara keseluruhan, transfer internal yang selesai dalam interaksi yang sama masih bisa dihitung sebagai FCR. Untuk KPI agen, perusahaan bisa memakai aturan berbeda.

Q:Berapa lama reopen window untuk FCR?

A:Tidak ada satu angka yang cocok untuk semua perusahaan. Tentukan periode berdasarkan jenis layanan, lalu gunakan aturan yang sama agar data bisa dibandingkan.

Sistem Call Center Udesk dengan konektivitas stabil dan fitur lengkap—coba gratis dan tingkatkan kualitas layanan telepon Anda.

Artikel ini merupakan karya asli Udesk. Jika akan diterbitkan ulang, wajib selalu mencantumkan sumber aslinya：https://id.udeskglobal.com/blog/first-call-resolution-rumus-fcr-dan-cara-meningkatkannya-di-contact-center