Portal self service pelanggan adalah salah satu proyek dengan leverage tertinggi yang bisa dipesan sebuah bisnis, sekaligus salah satu yang paling gampang salah eksekusi. Kalau dibangun dengan benar, portal ini menghilangkan pertanyaan repetitif yang menghabiskan waktu tim support: di mana pesanan saya, bisa minta salinan invoice ini, bagaimana status akun saya. Kalau salah dibangun, portal itu jadi sesuatu yang tidak dipakai siapa pun, karena dirancang berdasarkan asumsi tim IT tentang apa yang diinginkan pelanggan, bukan apa yang benar-benar mereka tanyakan.

Perbedaan antara dua hasil ini bukan soal kehalusan desain atau banyaknya fitur. Ini soal apakah portal dibangun dari data pelanggan yang nyata atau dari struktur organisasi internal. Saya pernah melihat sebuah perusahaan multifinance menghabiskan anggaran yang tidak sedikit untuk dashboard self-service dengan desain yang indah, tapi tidak pernah disentuh pelanggan, karena yang ditampilkan adalah pengaturan akun dan cross-sell produk, bukan satu hal yang paling sering ditelepon pelanggan: tanggal jatuh tempo pembayaran.

Gali data support Anda sebelum mendesain apa pun

Satu-satunya cara yang bisa diandalkan untuk mengetahui apa yang seharusnya ada di portal self service pelanggan adalah dengan melihat apa yang sudah ditanyakan pelanggan ke tim support Anda, dalam kata-kata mereka sendiri, selama periode yang cukup panjang. Tiga bulan log chat support, transkrip telepon, atau subjek tiket biasanya sudah cukup untuk melihat polanya dengan jelas.

Tarik datanya dan urutkan berdasarkan frekuensi, bukan berdasarkan apa yang terlihat penting:

  1. Ekspor tiket support atau transkrip chat dari tiga bulan terakhir.
  2. Kategorikan berdasarkan topik (cek status, permintaan dokumen, pertanyaan pembayaran, komplain, pertanyaan umum).
  3. Urutkan kategori berdasarkan volume.
  4. Ambil lima teratas. Itulah cakupan sebenarnya untuk versi pertama portal Anda.

Di hampir semua kasus yang pernah saya lihat, lima pertanyaan teratas adalah kombinasi dari: status pesanan atau pengajuan, salinan invoice atau kwitansi, informasi pembayaran atau jatuh tempo, unggah ulang atau resubmit dokumen, dan detail akun dasar. Tidak ada yang eksotis di sini. Justru inilah yang jarang dibangun lebih dulu, karena tim internal cenderung merancang portal di sekitar fitur yang menurut mereka menarik untuk dibangun, bukan lima hal yang terus-menerus ditanyakan pelanggan.

Bangun untuk lima teratas, bukan daftar fitur lengkap

Godaan dalam setiap proyek self-service adalah membuatnya komprehensif: pengaturan, preferensi, opt-in marketing, katalog produk, riwayat transaksi lengkap, chat support yang ditempel di layar yang sama. Komprehensif kedengarannya bagus di rapat perencanaan, tapi hasilnya adalah portal yang butuh waktu lebih lama untuk dinavigasikan pelanggan dibanding kalau mereka langsung menelepon.

Portal yang menjawab tepat lima pertanyaan nyata teratas, cepat dan tanpa alur login yang makan waktu tiga menit, akan dipakai. Portal dengan empat puluh fitur dengan lima yang penting terkubur di navigasi tidak akan dipakai, tidak peduli berapa besar biaya yang dikeluarkan untuk membangunnya. Batasi cakupan versi pertama secara ketat di sekitar data terurut dari log support Anda, luncurkan, dan baru tambahkan fitur setelah Anda memastikan penggunaan pada hal-hal esensial.

Ukur keberhasilan dari kontak yang teralihkan, bukan dari jumlah login

Metrik yang tepat untuk portal self service pelanggan bukan berapa banyak orang yang mendaftar. Yang penting adalah berapa banyak kontak support yang benar-benar berhasil dicegah portal itu. Lacak volume tiket atau telepon untuk lima kategori teratas Anda sebelum dan sesudah peluncuran. Kalau tiket terkait invoice turun 40% setelah Anda menambahkan fitur unduh invoice mandiri, itu adalah hasil nyata dan terukur yang bisa Anda tunjukkan. Jumlah login dan page view hanya menunjukkan orang menemukan portalnya; itu tidak menunjukkan portal itu benar-benar berfungsi.

Ini adalah disiplin yang sama yang berlaku untuk otomasi apa pun yang berhadapan langsung dengan pelanggan: bangun berdasarkan bukti apa yang benar-benar dilakukan pelanggan, bukan asumsi tentang apa yang seharusnya mereka inginkan. Prinsip yang sama muncul di Data Pelanggan: Kumpulkan Lebih Sedikit, Manfaatkan Lebih Banyak, di mana data paling bernilai adalah yang sudah dihasilkan, bukan data baru yang harus Anda kumpulkan.

Kapan portal belum layak dibangun

Tidak semua bisnis sudah berada di titik di mana portal self-service akan terbayar. Kalau volume support Anda untuk kategori pertanyaan tertentu masih rendah, katakanlah di bawah 20 kontak per bulan, biaya membangun dan memelihara fitur portal itu bisa jadi melebihi waktu support yang dihemat selama bertahun-tahun. Dalam kasus ini, halaman FAQ yang ditulis dengan baik atau template respons yang bisa dikirim tim Anda dalam hitungan detik adalah investasi yang lebih baik. Simpan pembangunan portal untuk kategori dengan volume nyata, di mana periode balik modalnya hitungan bulan, bukan tahun.

Di sinilah keputusan build-versus-buy juga berperan. Portal tidak perlu langsung jadi proyek engineering kustom sejak hari pertama; beberapa tool portal pelanggan siap pakai sudah cukup baik untuk menangani cek status dan pengambilan dokumen di versi pertama, dan membangun secara kustom baru layak dilakukan setelah volume dan kompleksitasnya membenarkannya. Kalau Anda sedang mempertimbangkan jalur pembangunan itu secara lebih serius, ada baiknya melakukan diskusi terstruktur sebelum mengalokasikan anggaran, yang persis seperti percakapan penentuan cakupan yang kami lakukan di /partner.

Intinya

Portal self service pelanggan hanya sepadan biayanya kalau dibangun dari data support yang nyata, cakupannya dibatasi ketat pada lima pertanyaan teratas yang benar-benar ditanyakan pelanggan, dan diukur dari kontak yang teralihkan, bukan dari catatan login. Hindari godaan untuk membangun secara komprehensif atau mencerminkan struktur departemen internal Anda ke dalam struktur portal. Gali datanya dulu, luncurkan secara sempit, ukur pengalihannya, baru kemudian perluas.