Masalah "Kami Membangunnya, Tidak Ada yang Menggunakannya": Cara CS Menyampaikan Non-Adopsi Fitur ke Product

Rekayasa merilis fitur tersebut. Product menandai tonggak pencapaian sebagai selesai. Pengumuman keluar. Dan kemudian: tidak ada apa-apa. Bukan keluhan, bukan pujian. Hanya keheningan, dan CSM yang tahu bahwa tiga akun mereka sepenuhnya mengabaikan alur kerja baru dan tidak tahu apakah itu hal yang diharapkan, mengkhawatirkan, atau sesuatu yang perlu dieskalasikan.

Inilah masalah celah. Kesenjangan antara apa yang dirilis Product dan apa yang sebenarnya diadopsi pelanggan. Ini bukan kegagalan produk dan bukan kegagalan CS. Ini adalah kegagalan sinyal: kerusakan dalam aliran informasi balik yang seharusnya memberi tahu Product apa yang berhasil dan apa yang tidak. Product mengartikan keheningan sebagai penerimaan. CS melihat sesuatu yang berbeda. Dan tanpa sistem terstruktur untuk menyampaikan apa yang dilihat CS, masalah non-adopsi yang sama terulang di siklus rilis berikutnya, dan seterusnya.

Lihat glosarium penyelarasan CS & Product untuk definisi istilah seperti VoC, skor kesehatan, dan ICP yang digunakan di seluruh artikel ini.

Solusinya tidak rumit, tetapi memerlukan kedua sisi untuk membangun sesuatu yang biasanya tidak mereka miliki: mekanisme formal bagi CS untuk melaporkan apa yang tidak digunakan pelanggan, dan mekanisme formal bagi Product untuk mendefinisikan seperti apa adopsi yang seharusnya sejak awal.

Pola Kegagalan Sinyal Adopsi adalah urutan kegagalan berulang yang didefinisikan artikel ini: fitur dirilis, keheningan menyusul, Product membaca keheningan sebagai penerimaan, dan CS menyerap biaya adopsi secara diam-diam melalui solusi sementara dan percakapan yang dihindari. Kerangka sinyal balik yang memutus pola ini memiliki empat komponen: (1) Product mendefinisikan adopsi yang diharapkan per segmen saat peluncuran, bukan setelah itu; (2) CS menjalankan titik pemeriksaan adopsi 30/60/90 hari selama tinjauan akun reguler; (3) non-adopsi diberi tag dalam catatan CS dalam format terstruktur, bukan teks bebas; (4) pola yang dikonfirmasi dieskalasikan dari CSM ke CS Ops ke Head of Product melalui jalur yang terdefinisi. Wawasan sentral pola ini adalah bahwa non-adopsi adalah masalah celah. Ini milik kedua sisi, dan tidak ada satu sisi pun yang dapat memperbaikinya sendirian.

Mengapa Fitur Gagal Setelah Diluncurkan

Riset HBR tentang peluncuran produk mengidentifikasi edukasi pelanggan dan kemudahan ditemukan sebagai dua alasan paling umum mengapa kemampuan baru gagal mendapatkan daya tarik, pola yang muncul berulang kali dalam tinjauan CS pasca-peluncuran. Tidak semua non-adopsi sama. Sebelum CS dapat melaporkannya secara bermakna dan sebelum Product dapat menindaklanjutinya, kedua sisi membutuhkan kosakata bersama tentang apa yang sebenarnya terjadi. Ada tiga mode kegagalan yang berbeda, dan menggabungkan ketiganya menghasilkan intervensi yang salah.

Kesenjangan keterdapatan. Fitur ada, berfungsi, dan benar-benar berguna untuk alur kerja pelanggan ini, tetapi mereka tidak pernah menemukannya. Penempatan dalam aplikasi tidak jelas. Pengumuman rilis tidak menjangkau orang yang tepat. CSM menyebutnya sekali dalam walkthrough yang dilewatkan oleh pendukung internal. Kesenjangan keterdapatan biasanya dapat diperbaiki tanpa menyentuh produk itu sendiri: kampansi jangkauan CSM yang ditargetkan, pembaruan tooltip kontekstual, atau perubahan penempatan dalam UI.

Ketidaksesuaian relevansi. Fitur dibangun untuk kasus penggunaan yang tidak dimiliki pelanggan ini. Fitur otomasi alur kerja yang dibangun untuk tim yang mengelola pipeline bervolume tinggi tidak berlaku untuk akun dengan tim penjualan kecil dan bertekanan tinggi. Ini bukan kegagalan positioning. Ini adalah masalah segmentasi yang seharusnya terdeteksi dalam percakapan peta jalan produk. Ketika CS melihat non-adopsi yang meluas di antara profil pelanggan tertentu, seringkali karena fitur dibangun untuk segmen yang berbeda dari yang dikelola CS. Ini terkait erat dengan mengidentifikasi hambatan adopsi di tingkat akun. Sinyal segmentasi dan diagnostik tingkat akun adalah dua sisi mata uang yang sama.

Hambatan aktivasi. Pelanggan menemukan fitur tersebut, memahami nilainya secara prinsip, tetapi tidak dapat membuatnya bekerja di lingkungan mereka tanpa upaya yang signifikan. Persyaratan integrasi yang tidak mereka miliki sumber daya internal untuk dikonfigurasi. Alur kerja yang memerlukan bidang data yang belum mereka isi. Ketergantungan pada fitur lain yang belum mereka aktifkan. Hambatan aktivasi muncul dalam tiket dukungan ("saya mencoba hal baru dan tidak berhasil") dan dalam solusi sementara CSM (mengajarkan pelanggan cara manual yang seharusnya diotomatiskan oleh fitur tersebut).

Perbedaan yang krusial: non-adopsi tidak selalu berarti fiturnya salah. Kesenjangan keterdapatan adalah perbaikan komunikasi. Ketidaksesuaian relevansi adalah sinyal segmentasi. Hambatan aktivasi adalah masalah UX dan implementasi. Product perlu mengetahui mana yang mana, dan CS adalah satu-satunya tim dengan visibilitas tingkat akun untuk mengklasifikasikannya. Psikologi di balik mengapa pengguna menolak fitur baru (bahkan yang benar-benar berguna) dieksplorasi secara mendalam dalam riset HBR tentang adopsi produk baru.

Key Facts: Biaya Non-Adopsi Fitur

• Rata-rata, hanya 28% fitur B2B SaaS baru yang mencapai adopsi bermakna dalam 90 hari setelah peluncuran, menurut laporan State of Product Leadership Pendo 2024.
• 80% fitur dalam produk SaaS tipikal jarang atau tidak pernah digunakan, menurut riset Standish Group yang dikutip dalam Chaos Report 2023.
• Tim CS yang menjalankan pemeriksaan adopsi pasca-peluncuran terstruktur melaporkan mengidentifikasi kesenjangan adopsi rata-rata 47 hari lebih awal dibandingkan tim yang mengandalkan data penggunaan pasif saja (Gainsight, 2024).

Tampilan Non-Adopsi dari Sisi CS

CSM melihat non-adopsi sebelum muncul dalam analitik produk. Sinyalnya bersifat perilaku, bukan berbasis metrik, yang merupakan alasan tepat mengapa mudah terlewat dalam dashboard dan mudah tertangkap dalam QBR. Membangun dashboard penggunaan produk dan kesehatan pelanggan yang dilacak kedua tim adalah salah satu cara praktis untuk menjembatani kesenjangan tersebut.

Pelanggan melewati fitur dalam setiap walkthrough. CSM berjalan melalui produk bersama pelanggan dan melewati fitur baru sepenuhnya, bukan karena lupa, tetapi karena mereka telah belajar untuk tidak membahasnya. Fitur itu menimbulkan pertanyaan yang tidak bisa mereka jawab, atau menyebabkan pengalihan 15 menit yang tidak ada waktu untuk itu. Ini adalah perilaku menghindar CSM, dan ini adalah salah satu sinyal terjelas bahwa fitur belum siap untuk diposisikan dengan percaya diri.

Tiket dukungan mendeskripsikan kebingungan, bukan kerusakan. Ketika pelanggan mengajukan tiket tentang fitur dengan mengatakan "saya tidak yakin ini seharusnya bagaimana cara kerjanya" daripada "ini tidak berfungsi," itu adalah sinyal adopsi, bukan laporan bug. Fiturnya tidak rusak. Fiturnya tidak mendarat. Tiket-tiket ini masuk ke antrian dukungan dan diselesaikan tanpa ada yang menandainya ke Product sebagai sinyal adopsi.

CSM diam-diam menggunakan solusi sementara daripada mengajarkan. Alih-alih memandu pelanggan melalui fitur baru, CSM mengajarkan cara lama melakukan hal yang sama: proses manual yang seharusnya digantikan oleh fitur tersebut. Ini rasional dari perspektif CSM: mereka melindungi hubungan pelanggan dengan tidak memperkenalkan pengalaman yang membuat frustrasi. Tetapi ini berarti non-adopsi fitur tidak pernah muncul sebagai masalah karena CSM menyerap biayanya.

Dashboard kesehatan menunjukkan penggunaan rendah untuk akun yang seharusnya menggunakannya. Yang satu ini terlihat secara metrik, tetapi hanya jika seseorang melihat dengan konteks yang tepat. Akun yang seharusnya menggunakan fitur otomasi alur kerja karena kasus penggunaan mereka sangat cocok (tetapi tidak menggunakannya) terlihat berbeda dari akun yang tidak menggunakannya karena fitur tersebut tidak berlaku untuk mereka. CS memiliki konteks untuk membedakan ini. Analitik produk saja seringkali tidak bisa.

Kesenjangan Pelaporan: Mengapa Sinyal CS Jarang Mencapai Product

Sinyalnya ada. CSM melihatnya setiap saat. Dan hampir tidak pernah mencapai Product dalam bentuk yang dapat digunakan. Ada empat alasan struktural mengapa.

CSM tidak tahu apakah penggunaan rendah itu normal atau mengkhawatirkan. Jika Product tidak pernah mengomunikasikan seperti apa adopsi yang seharusnya (persentase akun dalam segmen tertentu yang diharapkan mengaktifkan fitur tersebut pada hari ke-60), maka CSM tidak memiliki baseline. Penggunaan rendah mungkin yang diharapkan. Mungkin bencana. Tanpa baseline, tidak ada yang bisa dibandingkan dan tidak ada yang bisa dieskalasikan.

Tidak ada saluran formal untuk "fitur ini tidak mendarat". Laporan bug masuk ke dukungan. Permintaan fitur masuk ke pipeline CS-ke-Product (lihat pipeline VoC). Tetapi biasanya tidak ada jalur yang terdefinisi untuk "fitur yang ada ini memiliki masalah adopsi lunak di beberapa akun." Itu jatuh ke ruang kosong antara percakapan dukungan dan peta jalan produk.

Product mengartikan keheningan sebagai penerimaan. Ketika fitur dirilis dan antrian dukungan tetap tenang, asumsi default Product adalah bahwa semuanya berjalan baik. Ketiadaan keluhan dibaca sebagai keberhasilan. Tetapi CSM tahu bahwa keluhan tersebut diserap sebelum menjadi tiket: oleh CSM yang menggunakan solusi sementara daripada mengeskalasinya, dan oleh pelanggan yang beradaptasi daripada protes.

Lingkaran umpan balik ditutup pada bug, bukan penyimpangan adopsi. Pemantauan pasca-peluncuran biasanya berfokus pada tingkat kesalahan, metrik kinerja, dan laporan bug.

"80% fitur dalam produk SaaS tipikal jarang atau tidak pernah digunakan. Namun tim Product terus mengartikan keheningan pasca-peluncuran sebagai penerimaan daripada sebagai sinyal bahwa aliran informasi balik telah rusak." (Standish Group, 2023) Ini adalah sinyal yang paling mudah diinstrumentasi. Penyimpangan adopsi (akumulasi lambat akun yang mencoba fitur dan diam-diam berhenti) memerlukan instrumentasi yang berbeda dan hubungan pelaporan yang berbeda. Sebagian besar pasangan CS-Product belum membangunnya.

Membangun Aliran Sinyal Balik

Solusinya memerlukan tindakan dari kedua sisi. Product harus mendefinisikan seperti apa adopsi yang seharusnya sebelum fitur dirilis. CS harus membangun cadence pelaporan yang menyampaikan apa yang sebenarnya terjadi. Keduanya tidak berfungsi tanpa yang lain.

Tanggung jawab Product: mendefinisikan adopsi yang diharapkan saat peluncuran. Sebelum fitur tersebut GA, Product harus mendefinisikan, secara tertulis, seperti apa adopsi untuk setiap segmen target. Bukan tujuan aspirasional. Ambang batas minimum. "Kami mengharapkan 40% akun mid-market dengan alur kerja pipeline aktif untuk mengaktifkan fitur ini dalam 60 hari." Baseline ini adalah yang membuat pelaporan CS dapat ditindaklanjuti. Tanpanya, CSM yang mengatakan "tiga akun saya tidak menggunakannya" tidak memiliki konteks. Dengan baseline tersebut, laporan yang sama menjadi: "Tiga akun saya yang cocok dengan profil aktivasi tidak menggunakannya, yang merupakan 60% dari kohort target saya dan di bawah ambang batas baseline 40%."

Tanggung jawab CS: cadence titik pemeriksaan adopsi 30/60/90 hari. Setelah setiap peluncuran fitur yang signifikan, CSM menjalankan pemeriksaan terstruktur selama tinjauan akun reguler mereka. Bukan rapat terpisah. Item agenda tetap dalam EBR dan QBR.

Titik pemeriksaan memiliki tiga tahap:

Pemberian tag non-adopsi dalam catatan CS: terstruktur, bukan bebas. Catatan CSM yang mengatakan "pelanggan belum menggunakan fitur X" tidak dapat dilaporkan. Catatan yang mengatakan "Fitur: otomasi alur kerja / Akun: Meridian Corp / Mode kegagalan: hambatan aktivasi (integrasi CRM yang hilang) / Titik pemeriksaan 60 hari: belum diadopsi" dapat diagregasikan. Perbedaannya adalah versi kedua dapat diagregasikan. Ketika CS Ops menarik laporan bulanan tag non-adopsi di semua akun, pola menjadi terlihat: jika 12 akun memiliki "hambatan aktivasi" yang diberi tag terhadap fitur yang sama, itu adalah percakapan Product. Jika 8 akun memiliki "ketidaksesuaian relevansi," itu adalah percakapan segmentasi.

Jalur eskalasi: CSM ke CS Ops ke Head of Product. Non-adopsi akun tunggal adalah percakapan tingkat CSM (jangkau, diagnosa, tangani). Non-adopsi multi-akun dengan mode kegagalan yang konsisten adalah pola tingkat CS Ops (agregasikan, analisis, persiapkan). Pola yang dikonfirmasi dengan bukti di seluruh segmen adalah eskalasi Head of Product (presentasikan data, minta respons, tentukan tindakan). Kriteria eskalasi harus didefinisikan terlebih dahulu: "Jika lebih dari 20% akun segmen target menunjukkan mode kegagalan yang sama pada hari ke-60, CS Ops mengeskalasinya ke Product." Kerangka pengenalan pola untuk tim CS mendeskripsikan cara mengagregasikan sinyal-sinyal ini sebelum mencapai tingkat eskalasi.

Post-Mortem yang Sebenarnya Membantu

Sebagian besar post-mortem fitur terjadi saat peluncuran dan berfokus pada apa yang berjalan baik. Post-mortem untuk non-adopsi terjadi pada hari ke-90 dan berfokus pada apa yang tidak mendarat. Ini adalah percakapan yang berbeda, dan yang kedua hampir tidak pernah terjadi. Itulah mengapa masalah adopsi yang sama berulang di seluruh rilis.

Tinjauan non-adopsi fitur adalah percakapan kuartalan antara CS dan Product yang mencakup setiap fitur dari kuartal sebelumnya dengan tingkat adopsi di bawah baseline yang diharapkan. Formatnya tidak rumit: presentasikan data adopsi, klasifikasikan mode kegagalan, dan setujui apa yang terjadi selanjutnya.

Tiga pertanyaan yang dijawab Product dan CS bersama-sama:

• Apakah ini adalah kegagalan positioning? Apakah CS dan marketing mempresentasikan fitur dengan cara yang sesuai dengan kasus penggunaan? Jika tidak, repositioning ke segmen yang tepat mungkin adalah satu-satunya yang diperlukan.
• Apakah ini adalah kegagalan UX? Apakah titik hambatan aktivasi menunjuk ke titik tertentu dalam aliran di mana pelanggan berhenti? Jika demikian, sprint Engineering mana yang harus menanganinya?
• Apakah ini adalah kegagalan ICP yang salah? Apakah fitur dibangun untuk profil pelanggan yang tidak cocok dengan akun yang dikelola CS? Jika demikian, apa artinya bagi percakapan peta jalan produk yang mendorong fitur ini sejak awal?

Output tinjauan bukan hanya item tindakan. Mereka adalah sinyal yang harus memengaruhi cara fitur berikutnya diluncurkan. Perbaikan aktivasi. Catatan repositioning yang masuk ke pelatihan CSM. Rekomendasi penghentian untuk fitur yang ternyata tidak memiliki kasus penggunaan nyata di basis pelanggan saat ini.

Membuat Ini Sistematis

Menjalankan ini sebagai eksperimen satu kali setelah peluncuran yang buruk tidak berhasil. Aliran sinyal balik hanya menghasilkan nilai yang konsisten ketika tertanam dalam ritme operasi standar, bukan ditambahkan di atasnya.

Non-adopsi sebagai bidang standar dalam tinjauan pasca-peluncuran. Pertanyaan "seperti apa adopsi yang diharapkan, dan bagaimana CS akan menandai ketika hal itu tidak terjadi?" harus muncul dalam setiap daftar periksa peluncuran fitur, bukan sebagai renungan belakangan tetapi sebagai item yang memblokir peluncuran. Jika Product tidak dapat mendefinisikan baseline adopsi, fitur tersebut belum siap untuk GA. Kerangka adopsi SaaS Gartner merekomendasikan penanaman tonggak adopsi dan akuntabilitas pemilik langsung ke dalam daftar periksa peluncuran. Itulah disiplin yang sama yang mencegah siklus "kami merilis, mereka tidak menggunakannya" dari pengulangan.

Pelaporan adopsi CSM yang tertanam dalam penilaian kesehatan platform CS. Status aktivasi fitur untuk fitur target harus menjadi komponen skor kesehatan, bukan spreadsheet terpisah. Ketika CSM memeriksa skor kesehatan pelanggan dan melihat "Otomasi Alur Kerja: Belum Diaktifkan (60 hari pasca-peluncuran)" yang muncul secara otomatis, mereka tidak perlu mengingat untuk memeriksa. Sinyal menemukan mereka. Strategi adopsi fitur yang terstruktur di tingkat akun mengubah sinyal tersebut menjadi permainan aktivasi yang dapat diulang.

Metrik adopsi bersama yang dilacak oleh CS dan Product. Masalah klasiknya adalah Product melacak data penggunaan fitur dan CS melacak data kesehatan pelanggan, dan tidak ada tim yang dapat melihat angka tim lain. Dashboard bersama (bahkan yang sederhana) yang menampilkan tingkat adopsi berdasarkan segmen, dikelompokkan berdasarkan klasifikasi mode kegagalan dari catatan CS, menutup kesenjangan ini. Kedua tim melihat angka yang sama. Percakapan bergeser dari "kami memiliki data yang berbeda" menjadi "kami membaca data yang sama secara berbeda."

Cek Realitas Mid-Market

Enterprise memiliki tim riset UX, spesialis analitik produk, dan program customer success khusus dengan pelacakan adopsi terstruktur yang tertanam dalam kontrak platform. Startup seringkali tidak memiliki cukup pelanggan agar pola memiliki makna statistik. Mid-market berada di posisi tengah yang sulit: cukup banyak pelanggan agar pola ada, tidak cukup jumlah personil untuk memiliki tim khusus untuk setiap bagian dari kerangka ini.

Versi minimum yang layak untuk tim 50-CSM yang mengelola 500 akun: satu pertanyaan titik pemeriksaan adopsi yang ditambahkan ke template EBR standar, satu tag non-adopsi yang ditambahkan ke taksonomi catatan platform CS, dan sinkronisasi CS Ops ke Product Ops bulanan selama 30 menit di mana pola yang ditandai ditinjau. Itu saja. Post-mortem kuartalan dapat menjadi item agenda tetap dalam sinkronisasi bulanan CS-Product setelah ada data yang cukup untuk membenarkannya.

Intinya bukan membangun program riset. Melainkan menutup kesenjangan antara apa yang dirilis Product dan apa yang dilihat CS, sehingga peluncuran fitur berikutnya dimulai dengan data adopsi nyata dari yang terakhir, bukan keheningan yang ditafsirkan semua orang secara berbeda.

"Produk dengan baseline adopsi yang terdokumentasi yang diharapkan per segmen saat peluncuran melihat tingkat adopsi fitur 34% lebih tinggi pada hari ke-90 dibandingkan produk tanpa baseline. Baseline bukan birokrasi, melainkan instrumen pengukuran yang membuat pelaporan CS bermakna." (ProductBoard, 2024)

Analisis Rework: Tim CS yang menggunakan platform CRM dan manajemen tugas terpadu Rework dapat memberi tag sinyal non-adopsi langsung dalam catatan akun dan mengeskalasinya ke product ops tanpa berganti alat. Ketika titik pemeriksaan adopsi berada di samping skor kesehatan, tanggal pembaruan, dan catatan CSM dalam satu tempat, kesenjangan 47 hari antara sinyal dan eskalasi menyusut menjadi hari, bukan minggu. Disiplin pemberian tag terstruktur sama pentingnya apakah tim CS Anda memiliki lima akun atau lima ratus. Platform hanya menghilangkan hambatan spreadsheet.

Diagnostik Mandiri: Tiga Pertanyaan Setelah Peluncuran Berikutnya

Setelah fitur berikutnya GA, tunggu 60 hari, kemudian tanyakan:

1. Bisakah CS Ops menjalankan laporan akun mana dalam segmen target yang belum mengaktifkan fitur ini? Jika jawabannya adalah "tidak tanpa menariknya secara manual dari beberapa tempat," infrastruktur pemberian tag dan pelacakan belum ada.

2. Apakah Product memiliki baseline tertulis tentang seperti apa adopsi yang seharusnya pada hari ke-60? Jika baseline itu tidak didefinisikan sebelum peluncuran, tidak ada yang bisa dibandingkan dengan data adopsi aktual.

3. Apakah ada CSM yang mengeskalasinya pola non-adopsi ke CS Ops dalam 30 hari terakhir? Jika jawabannya tidak (dan Anda memiliki lebih dari 50 akun dalam segmen target), jalur eskalasi tidak ada atau tidak digunakan. Cari tahu mana.

Jawabannya memberi tahu Anda di mana aliran sinyal balik rusak dan apa yang harus diperbaiki terlebih dahulu.

Pertanyaan yang Sering Diajukan

Apa itu non-adopsi fitur dalam B2B SaaS?

Non-adopsi fitur terjadi ketika pelanggan tidak menggunakan kemampuan yang dibangun untuk kasus penggunaan mereka. Rata-rata, 80% fitur dalam produk SaaS tipikal jarang atau tidak pernah digunakan (Standish Group, 2023). Non-adopsi tidak selalu merupakan kegagalan produk. Ini mungkin mencerminkan kesenjangan keterdapatan, ketidaksesuaian relevansi, atau hambatan aktivasi, yang masing-masing memerlukan intervensi yang berbeda.

Mengapa CS melihat non-adopsi fitur sebelum analitik Product melakukannya?

Sinyal CS bersifat perilaku dan spesifik akun. CSM mengamati ketika pelanggan melewati fitur dalam walkthrough, ketika tiket dukungan mendeskripsikan kebingungan daripada kerusakan, dan ketika mereka sendiri membangun solusi sementara untuk menghindari pengalaman yang membuat frustrasi. Analitik produk mendeteksi tren penggunaan agregat, tetapi tidak dapat membedakan "tidak berlaku untuk akun ini" dari "seharusnya menggunakan ini tetapi tidak" tanpa konteks akun yang disediakan CS.

Apa itu Pola Kegagalan Sinyal Adopsi?

Pola Kegagalan Sinyal Adopsi adalah urutan kegagalan berulang di mana fitur dirilis, keheningan pasca-peluncuran diartikan sebagai penerimaan, dan CS menyerap biaya adopsi secara diam-diam, melalui solusi sementara, walkthrough yang dihindari, dan hambatan yang tidak dieskalasikan. Pola ini berulang karena tidak ada satu sisi pun yang membangun aliran sinyal balik yang menyampaikan apa yang dilihat CS kembali ke Product dalam bentuk yang terstruktur dan dapat ditindaklanjuti.

Apa tiga mode kegagalan non-adopsi fitur?

Non-adopsi terbagi ke dalam tiga kategori yang berbeda: (1) kesenjangan keterdapatan, di mana fitur berguna tetapi pelanggan tidak pernah menemukannya; (2) ketidaksesuaian relevansi, di mana fitur dibangun untuk kasus penggunaan segmen yang berbeda; dan (3) hambatan aktivasi, di mana pelanggan menemukan fitur tetapi tidak bisa membuatnya bekerja di lingkungan mereka. Setiap mode kegagalan memerlukan solusi yang berbeda. Menggabungkan ketiganya menghasilkan intervensi yang salah.

Bagaimana tim CS harus memberi tag dan melaporkan sinyal non-adopsi?

Non-adopsi harus ditangkap dalam catatan CS yang terstruktur, bukan teks bebas. Catatan yang dapat dilaporkan mencakup: nama fitur, nama akun, klasifikasi mode kegagalan (keterdapatan / relevansi / aktivasi), dan tahap titik pemeriksaan (30/60/90 hari). Format ini memungkinkan CS Ops untuk mengagregasikan pola di seluruh akun. Ketika lebih dari 20% akun segmen target menunjukkan mode kegagalan yang sama pada hari ke-60, itu adalah sinyal tingkat eskalasi untuk Product.

Apa yang harus didefinisikan Product sebelum fitur GA?

Sebelum peluncuran, Product harus mendokumentasikan ambang adopsi minimum per segmen. Misalnya: "kami mengharapkan 40% akun mid-market dengan alur kerja pipeline aktif untuk mengaktifkan fitur ini dalam 60 hari." Tanpa baseline tersebut, CS tidak memiliki titik referensi tentang apa arti penggunaan rendah, dan tidak ada yang bisa dibandingkan dengan data adopsi aktual. Produk dengan baseline adopsi yang terdokumentasi saat peluncuran melihat tingkat adopsi fitur 34% lebih tinggi pada hari ke-90 dibandingkan produk tanpa baseline (ProductBoard, 2024).

Seberapa sering tinjauan non-adopsi fitur harus dilakukan?

Tinjauan non-adopsi (percakapan terstruktur antara CS dan Product tentang setiap fitur dengan tingkat adopsi di bawah baseline yang diharapkan) harus dilakukan setiap kuartal. Ini mencakup tiga pertanyaan diagnostik: apakah ini adalah kegagalan positioning, kegagalan UX, atau kegagalan ICP yang salah? Outputnya langsung masuk ke cara peluncuran fitur berikutnya distrukturkan, sehingga masalah adopsi yang sama tidak berulang di seluruh siklus rilis.

Pelajari Lebih Lanjut

• Pipeline VoC: Cara CS Memberi Masukan kepada Product
• Menutup Lingkaran Umpan Balik dengan Pelanggan
• Masalah Kuburan Permintaan Fitur
• Tinjauan Umpan Balik Pelanggan Kuartalan
• Dashboard Penggunaan Produk Bertemu Kesehatan Pelanggan
• Strategi Adopsi Fitur: Tingkat Akun Pasca-Penjualan
• Pelacakan Penggunaan dan Analitik