Mengelola program CX lintas fungsi

Journey map paling indah yang pernah saya lihat mati bukan di depan pelanggan, melainkan di ruang rapat lintas fungsi lantai delapan. Semua orang mengangguk, semua orang setuju prioritasnya, dan tiga bulan kemudian tidak satu pun dari enam fungsi yang terlibat bisa menjawab siapa yang sebenarnya bertanggung jawab menutup gap-nya. Itu bukan kegagalan desain. Itu kegagalan operasi.

Program CX lintas fungsi tidak gagal karena visinya buruk — mereka gagal karena tidak ada satu pemilik akuntabel, tidak ada forum keputusan yang rutin, dan tidak ada metrik bersama yang memaksa setiap fungsi menanggung dampaknya terhadap pengalaman pelanggan, bukan hanya terhadap KPI departemennya sendiri. Begitu tanggung jawab tersebar rata ke banyak fungsi tanpa satu titik akuntabilitas, ia berhenti menjadi tanggung jawab siapa pun.

Mengapa program CX lintas fungsi sering berhenti di tengah jalan?

Karena struktur organisasi dirancang untuk efisiensi vertikal, bukan untuk perjalanan pelanggan yang horizontal. Contact center melapor ke Operasi. Aplikasi mobile milik Digital. Kebijakan komplain milik Legal atau Compliance. Retensi milik Marketing. Pelanggan tidak peduli dengan struktur ini — ia hanya mengalami satu perjalanan yang terus terpotong setiap kali melewati batas departemen.

Psikolog sosial Bibb Latané dan John Darley menyebut fenomena ini diffusion of responsibility — semakin banyak orang yang hadir dan "punya andil" dalam sebuah situasi, semakin kecil kemungkinan satu individu merasa wajib bertindak, karena setiap orang berasumsi orang lain akan menanganinya. Riset klasik mereka pada 1968 tentang perilaku menyaksikan kejadian darurat membuktikan pola ini pada manusia dalam kelompok — dan pola yang sama muncul di rapat steering committee CX yang dihadiri sembilan kepala departemen tanpa satu pun yang punya mandat eksekusi.

Program CX lintas fungsi yang sehat melawan pola ini secara struktural, bukan dengan menyuruh orang "lebih peduli pelanggan". Ia memberi satu fungsi atau satu peran mandat eksplisit untuk menutup gap, sementara fungsi lain berkontribusi sebagai pemilik proses yang bertanggung jawab pada bagiannya. Ini yang sering hilang dari struktur governance CX yang dirancang sebagai komite tanpa gigi eksekusi.

Apa beda "proyek CX" dengan "program CX" — dan mengapa perbedaan ini penting?

Proyek punya tanggal selesai. Program tidak. Proyek CX biasanya lahir dari satu inisiatif — merombak alur onboarding, meluncurkan chatbot, memperbaiki skrip komplain — dengan anggaran, timeline, dan definisi selesai yang jelas. Program CX lintas fungsi adalah kapabilitas permanen: kemampuan organisasi untuk terus mendengar, mengukur, memprioritaskan, dan memperbaiki pengalaman pelanggan lintas kanal dan lintas fungsi, selamanya.

Kesalahan paling umum yang saya lihat di perusahaan menengah-besar adalah memperlakukan program sebagai rangkaian proyek. Setelah proyek journey mapping selesai, tim dibubarkan, dokumen disimpan di SharePoint, dan enam bulan kemudian tidak ada yang tahu apakah rekomendasinya dijalankan. Program yang bertahan punya ritme operasi tetap — bukan kick-off dan closing, melainkan siklus ulang: dengar, ukur, prioritaskan, eksekusi, ulang.

Riset Bain & Company dalam laporan Closing the Delivery Gap (2005, dipublikasikan di bain.com) menemukan bahwa 80% perusahaan yakin mereka memberikan pengalaman superior, sementara hanya 8% pelanggan mereka setuju. Gap sebesar itu tidak lahir dari kurangnya niat baik — ia lahir dari kurangnya mekanisme yang memaksa niat baik itu bertemu realitas operasional lintas fungsi, terus-menerus, bukan sekali proyek.

Siapa yang seharusnya memiliki program CX lintas fungsi?

Satu peran, dengan mandat yang jelas dan akses langsung ke pengambil keputusan senior — bukan komite. Peran ini bisa disebut Head of CX, CX Program Office, atau Direktur Transformasi CX, tapi jabatannya kurang penting dibanding tiga hal yang harus ia miliki:

• Otoritas untuk memprioritaskan lintas fungsi — kemampuan menentukan bahwa inisiatif CX A lebih penting dieksekusi bulan ini dibanding fitur B yang diinginkan tim produk, dan keputusan itu mengikat.
• Akses ke data operasional lintas kanal — bukan hanya skor NPS, tapi data volume komplain, waktu penyelesaian, dan alasan churn dari sistem yang dimiliki fungsi lain.
• Anggaran atau pengaruh anggaran — tanpa ini, program CX menjadi rekomendasi tanpa gigi; setiap fungsi bisa dengan sopan mengabaikannya karena tidak ada konsekuensi.

Fungsi-fungsi lain — Operasi, Digital, HR, Marketing, Legal — tetap memiliki eksekusi di area mereka. Program office tidak menjalankan semua perbaikan; ia memastikan perbaikan yang tepat dijalankan oleh pemilik yang tepat, dengan urutan yang tepat. Ini beda mendasar dari model "CX sebagai polisi" yang hanya mengaudit dan mengeluh, dan salah satu alasan mengapa roadmap implementasi CX harus mencantumkan nama pemilik di setiap baris, bukan hanya nama inisiatif.

Bagaimana membangun model operasi CX lintas fungsi yang benar-benar bertahan?

Model operasi yang bertahan bukan yang paling elegan di slide, melainkan yang paling sedikit bergantung pada kemauan baik individu. Berikut urutan yang saya pakai saat membangun ulang operating model CX untuk organisasi yang programnya sudah dua kali gagal sebelumnya:

1. Petakan kepemilikan nyata, bukan kepemilikan di atas kertas. Untuk setiap touchpoint utama dalam perjalanan pelanggan, tulis nama fungsi dan nama orang yang benar-benar bisa mengubahnya minggu ini — bukan yang tertulis di struktur organisasi.
2. Bentuk forum keputusan tetap dengan kadensa jelas. Bulanan untuk keputusan prioritas, mingguan untuk eksekusi teknis. Forum tanpa jadwal tetap akan mati begitu satu krisis operasional muncul.
3. Tentukan satu metrik bersama yang dipantau semua fungsi — bukan lima metrik berbeda milik lima departemen. Ini memaksa percakapan tentang trade-off, bukan pembenaran silo.
4. Berikan program office hak veto atau eskalasi untuk inisiatif yang berdampak negatif pada pengalaman pelanggan, meski secara teknis "benar" bagi fungsi yang mengusulkannya.
5. Bangun jalur eskalasi yang cepat untuk isu yang menyangkut lebih dari satu fungsi, agar tidak menunggu rapat bulanan berikutnya untuk sesuatu yang sudah menyakiti pelanggan hari ini — lihat juga bagaimana strategi eskalasi yang jelas mencegah masalah kecil menjadi krisis publik.
6. Ukur maturitas program setiap dua kuartal, bukan hanya hasil pelanggan, untuk melihat apakah kapabilitas lintas fungsi benar-benar menguat atau hanya bertahan berkat satu orang yang gigih.
7. Rancang exit plan untuk sponsor eksekutif — program yang hanya hidup karena satu direktur peduli akan mati begitu direktur itu pindah posisi.

Langkah ketujuh ini sering diabaikan, dan paling sering menjadi sebab kematian program di tahun kedua. Saya membahas pola kegagalan tahun kedua ini lebih dalam di artikel tentang roadmap maturitas CX yang bertahan lewat tahun kedua — pola yang hampir selalu sama: energi besar di tahun pertama, lalu kolaps begitu sponsor berganti atau anggaran ditinjau ulang.

Mengapa forum lintas fungsi yang rutin justru sering diam-diam dibunuh oleh birokrasi kecil?

Karena "sludge" — istilah yang dipopulerkan ekonom Richard Thaler dalam artikelnya Nudge, Not Sludge, dipublikasikan di jurnal Science pada 2018 — merujuk pada friksi administratif yang membuat tindakan yang benar menjadi lebih sulit dari yang seharusnya. Dalam program CX lintas fungsi, sludge muncul sebagai formulir persetujuan tujuh langkah untuk mengubah satu skrip contact center, atau rapat prasyarat sebelum rapat keputusan yang sebenarnya.

Efeknya kumulatif. Setiap lapisan sludge menambah alasan bagi fungsi yang enggan berubah untuk menunda. Program office yang serius menghitung ulang setiap proses persetujuan dengan satu pertanyaan sederhana: langkah ini melindungi pelanggan atau organisasi dari risiko nyata, atau hanya melindungi seseorang dari harus membuat keputusan? Jika jawabannya yang kedua, hapus langkahnya. Ini bukan soal mempercepat sembarangan — beberapa gerbang persetujuan memang perlu untuk risiko regulasi atau finansial. Tapi kebanyakan sludge dalam operasi CX lahir dari kehati-hatian yang sudah tidak proporsional dengan risikonya.

Metrik apa yang benar-benar menyatukan fungsi yang berbeda kepentingan?

Metrik yang menyatukan bukan metrik yang paling canggih, melainkan yang paling sulit dihindari tanggung jawabnya. NPS agregat perusahaan gagal menyatukan karena setiap fungsi bisa berdalih skor buruk disebabkan fungsi lain. Yang berhasil adalah metrik yang dipecah per touchpoint dan per momen kritis (moment of truth) — di mana satu fungsi tidak bisa lagi bersembunyi di balik rata-rata perusahaan.

Praktik service blueprinting — memetakan setiap tindakan pelanggan berdampingan dengan proses back-office dan sistem pendukung yang menghasilkannya — adalah alat paling efektif untuk ini, karena ia secara visual menunjukkan siapa memegang kendali di titik mana pengalaman rusak. Nielsen Norman Group menjelaskan pendekatan ini secara rinci dalam artikel Service Blueprints: Definition. Ketika fungsi melihat nama mereka tertulis jelas di kolom "pemilik proses" pada momen yang mendapat skor buruk, argumen "ini bukan urusan saya" menjadi jauh lebih sulit dipertahankan di depan pimpinan lainnya.

Kombinasi yang saya rekomendasikan untuk kebanyakan program: satu metrik pengalaman inti yang dipantau di level dewan (misalnya skor pengalaman gabungan pada moment of truth kritis), dipecah menjadi metrik operasional per fungsi (waktu tanggap, tingkat penyelesaian di kontak pertama, akurasi janji layanan) yang muncul di scorecard masing-masing kepala departemen. Ini menyambungkan bahasa eksekutif dengan bahasa operasional — dua hal yang di kebanyakan organisasi tidak pernah bertemu di dokumen yang sama.

Bagaimana mengatasi resistensi middle management yang paling sering menenggelamkan program CX?

Resistensi middle management jarang datang dari ketidaksetujuan terbuka — ia datang dari penundaan halus, prioritas yang "sementara" dialihkan, dan komitmen verbal yang tidak pernah muncul di rencana kerja mingguan. Ini bukan soal karakter buruk. Ini loss aversion yang sangat rasional: manajer menengah menanggung risiko nyata (target kuartalan yang sudah ditetapkan, tim yang sudah kelebihan kapasitas) untuk manfaat yang samar dan jangka panjang (pengalaman pelanggan yang lebih baik, yang hasilnya belum tentu terlihat di scorecard mereka sendiri).

Cara mengatasinya bukan dengan lebih banyak sosialisasi, melainkan dengan menghilangkan risiko yang mereka rasakan. Ini berarti:

• Menyelaraskan target program CX ke dalam KPI resmi manajer menengah, bukan menambahkannya sebagai "inisiatif tambahan" di luar target utama mereka.
• Memberi kapasitas eksekusi nyata — waktu, anggaran kecil, atau akses ke tim teknis — bukan hanya instruksi untuk "lebih memperhatikan CX".
• Menunjukkan kemenangan cepat yang kredibel di area mereka sendiri dalam sembilan puluh hari pertama, sehingga program terasa sebagai bantuan, bukan beban tambahan.

Ini juga sebab utama mengapa manajemen perubahan yang serius dan program CX lintas fungsi tidak bisa dipisahkan. Struktur governance yang bagus tanpa strategi mengubah perilaku pemangku kepentingan hanya menghasilkan dokumen yang rapi dan eksekusi yang macet.

Bagaimana peran teknologi dalam menjaga program CX lintas fungsi tetap hidup, bukan hanya tercatat?

Kebanyakan program CX mati bukan karena strateginya salah, melainkan karena satu-satunya jejak eksekusinya adalah slide deck yang diperbarui manual setiap kuartal. Ketika journey map, skor pengalaman, dan roadmap perbaikan hidup di tiga sistem berbeda yang tidak saling bicara, tidak ada satu orang pun yang punya gambaran utuh — dan itulah kondisi ideal bagi diffusion of responsibility untuk kembali muncul.

Platform seperti René Studio dibangun untuk menutup gap ini dengan menjadikan perjalanan pelanggan sebagai data hidup, bukan dokumen statis: setiap touchpoint diberi skor Experience Impact Score yang transparan, setiap kelemahan yang teridentifikasi bisa langsung diubah menjadi inisiatif roadmap dengan pemilik dan tenggat waktu, dan setiap fungsi bisa melihat kontribusinya pada arc emosional pelanggan secara real time, bukan lewat laporan yang sudah basi tiga minggu. Ini bukan pengganti governance yang jelas — tapi ia membuat governance itu terlihat dan bisa ditagih, yang untuk program lintas fungsi sering menjadi beda antara hidup dan mati diam-diam.

Bagaimana mengukur apakah program CX lintas fungsi Anda benar-benar berjalan, bukan sekadar ada?

Tanda paling jujur bukan skor kepuasan pelanggan — itu indikator akhir yang bergerak lambat. Tanda paling jujur adalah kecepatan dan konsistensi eksekusi lintas fungsi itu sendiri. Beberapa pertanyaan diagnostik yang saya pakai saat mengaudit program yang sudah berjalan satu tahun:

• Bisakah lima orang dari fungsi berbeda menyebutkan momen kritis (moment of truth) yang sama sebagai prioritas nomor satu, tanpa saling berkonsultasi dulu?
• Berapa lama rata-rata waktu antara temuan masalah lintas fungsi dan keputusan resmi untuk menanganinya?
• Apakah ada inisiatif yang tertunda lebih dari dua kuartal tanpa ada yang secara formal menutupnya atau membatalkannya?

Jika jawabannya menyedihkan, itu bukan alasan membubarkan program — itu sinyal bahwa struktur akuntabilitasnya perlu diperbaiki, bukan orangnya. Sebuah asesmen maturitas CX yang menyeluruh, atau versi cepatnya lewat alat penilaian maturitas CX berbasis AI, biasanya bisa menunjukkan dengan tepat di lapisan mana — governance, kapabilitas, atau budaya — kemacetan itu terjadi.

Yang bertahan bukan program paling ambisius, tapi yang paling sulit diabaikan

Program CX lintas fungsi tidak mati karena krisis besar. Ia mati pelan-pelan, satu rapat yang dibatalkan demi urusan lain, satu keputusan yang ditunda "sampai kuartal berikutnya", satu sponsor yang pindah divisi tanpa pengganti yang jelas. Yang membuat program bertahan bukan kegembiraan di peluncuran, melainkan seberapa sulit ia untuk diabaikan ketika hal lain terasa lebih mendesak. Itu urusan struktur, bukan semangat — dan struktur itu bisa, dan harus, dirancang sejak hari pertama, bukan diperbaiki setelah tahun kedua gagal.

Jika tim Anda sedang membangun atau memperbaiki operating model CX lintas fungsi, tim kami di Renascence biasa membantu merancang program CX yang bertumpu pada governance nyata, bukan komitmen verbal. Hubungi kami untuk mendiskusikan di mana program Anda sekarang berdiri.