Menghentikan Fitur: Cara Menonaktifkan Fungsionalitas Tanpa Kehilangan Pelanggan yang Bergantung Padanya

Inilah skenario yang mengubah keputusan produk yang sederhana menjadi krisis retensi: sebuah fitur yang digunakan oleh 4% akun, tetapi menjadi tumpuan bagi tiga dari sepuluh pelanggan terbesar Anda. Product memutuskan untuk menghentikan fitur tersebut. Biaya pemeliharaannya tidak sebanding dengan tingkat penggunaannya, ada kemampuan baru yang lebih masuk akal secara arsitektur, dan 96% akun tidak akan menyadari kepergiannya. Keputusan itu masuk akal di atas kertas.

Kemudian pemberitahuan 30 hari dikirimkan. CS mengetahuinya di minggu yang sama saat pelanggan menerimanya. Pelanggan yang bergantung pada fitur tersebut bukan pengguna kasual dari 4% itu. Mereka adalah pihak yang telah membangun alur kerja di sekitar fitur itu, melatih tim mereka menggunakannya, dan dalam beberapa kasus mengintegrasikannya melalui API. Mereka juga adalah pihak yang ARR-nya mewakili persentase signifikan dari buku pembaruan Anda. Mereka melakukan eskalasi. Customer Success (CS) menjawab panggilan tanpa bahasa yang disetujui, tanpa panduan migrasi, dan tanpa pemahaman tentang kapan keputusan itu dibuat atau mengapa. Ini adalah contoh klasik manajemen akun berisiko. Akun yang paling mungkin berpindah setelah penghentian fitur adalah akun yang seharusnya sudah masuk dalam daftar pengawasan sebelum pemberitahuan dikirim.

Perpindahan pelanggan yang terjadi kemudian bukanlah sesuatu yang tak terhindarkan. Itu adalah hasil dari kegagalan proses: CS dilibatkan terlambat.

Mengapa Fitur Dihentikan, dan Mengapa Hal Itu Penting bagi Komunikasi

Alasan sebuah fitur dihentikan menentukan cara CS membingkai percakapan dengan pelanggan. Salah mengartikan alasan, atau menggunakan penjelasan generik, membuat komunikasi terasa korporat dan tidak relevan dengan pengalaman nyata pelanggan. Kerangka penonaktifan produk Gartner menggunakan "6M" (message, motive, meaning, mitigation, migration, dan method) justru karena setiap alasan penghentian memerlukan pembingkaian yang berbeda di keenam dimensi tersebut.

Utang teknis: Fitur ini memerlukan biaya pemeliharaan yang lebih besar dari yang bisa dibenarkan oleh penggunaannya. Pembingkaian yang jujur adalah: "Kami mengalokasikan kembali sumber daya rekayasa untuk membangun kemampuan yang melayani lebih banyak pelanggan kami." Ini dapat dipertanggungjawabkan, dan pelanggan yang memahami ekonomi produk SaaS akan menerimanya, asalkan disampaikan secara langsung.

Pergeseran strategis: Produk bergerak ke arah yang tidak cocok dengan fitur tersebut. Pelanggan mungkin menganggap ini sebagai produk yang menjauh dari mereka. CS perlu mampu menjelaskan arah strategis dalam istilah yang dipedulikan pelanggan: apa arti pergeseran ini bagi kemampuan yang paling sering mereka gunakan? Apa yang sedang dibangun sebagai penggantinya?

Konsolidasi: Sebuah fitur baru menggantikan dua fitur lama, tetapi penggantinya tidak satu banding satu. Ini adalah skenario paling berbahaya bagi CS, karena "kami membangun sesuatu yang lebih baik" seringkali tidak benar dari sudut pandang pelanggan individual. Jika fitur baru tidak mendukung kasus penggunaan spesifik mereka, konsolidasi itu adalah kerugian bersih bagi mereka. Bersikaplah jujur tentang hal itu.

Kepatuhan atau keamanan: Fitur tersebut telah menjadi kewajiban. Ini adalah alasan yang paling mudah dikomunikasikan karena bersifat eksternal, bukan preferensi produk, melainkan sebuah persyaratan. Pelanggan memahami kepatuhan. Mereka mungkin tidak menyukainya, tetapi akan menerima penjelasan yang jelas.

Masing-masing alasan ini memerlukan kalimat pembuka yang berbeda dalam percakapan dengan pelanggan. Bahasa generik seperti "kami selalu melakukan peningkatan" tidak melayani satupun dari mereka. Namun pola yang menghasilkan hasil terburuk bukan sekadar pesan yang salah. Melainkan proses yang salah.

Key Facts: Risiko Retensi saat Penghentian Fitur

• 79% perpindahan pelanggan B2B SaaS yang terkait dengan penghentian fitur dapat dicegah dengan keterlibatan CS lebih awal dalam proses penghentian, menurut riset retensi pelanggan Gainsight.
• Perusahaan yang memberi tahu pelanggan tentang penghentian fitur dengan pemberitahuan 90+ hari mengalami tingkat perpindahan pelanggan 3,2x lebih rendah di antara akun yang terdampak dibandingkan dengan pemberitahuan 30 hari, menurut data benchmark ChurnZero.
• Akun yang berada dalam jendela pembaruan pada saat penghentian fitur memiliki probabilitas perpindahan 2,7x lebih tinggi dibandingkan akun di luar jendela pembaruan, kecuali jika mereka menerima percakapan migrasi proaktif dari CSM mereka, menurut analisis retensi Totango.

Pola Kegagalan Penyelarasan

Pola yang menghasilkan hasil retensi terburuk konsisten di berbagai perusahaan. Ini juga merupakan salah satu tanda peringatan dalam 8 tanda peringatan ketidakselarasan CS-product: ketika CS di-CC pada email pelanggan pada waktu yang sama dengan saat pelanggan menerimanya, hubungan tersebut sudah rusak di tingkat proses.

1. Product membuat keputusan penghentian dalam rapat peta jalan produk, tanpa masukan CS
2. Legal atau product ops menulis pemberitahuan penghentian
3. CS di-CC pada email ketika dikirim ke pelanggan (secara bersamaan, bukan sebelumnya)
4. CSM menerima eskalasi pelanggan tanpa bahasa yang disetujui dan tanpa konteks produk
5. Akun berisiko tidak teridentifikasi sampai percakapan pembaruan, yaitu 30-90 hari terlambat
6. CSM individual menegosiasikan perpanjangan informal atau solusi sementara yang menciptakan preseden yang tidak disengaja siapapun

Proses yang tepat membalik hal ini sepenuhnya: CS dilibatkan sebelum keputusan penghentian diselesaikan, akun berisiko diidentifikasi sebelum komunikasi eksternal apa pun dikirimkan, dan CSM diberikan pengarahan dengan bahasa yang disetujui sebelum percakapan pelanggan pertama terjadi.

Langkah 1: Mengidentifikasi Siapa yang Bergantung pada Fitur

Ini adalah langkah yang harus dilakukan sebelum jadwal penghentian ditetapkan, bukan setelahnya.

Perbedaan yang penting adalah antara penggunaan dan ketergantungan. Pelanggan yang menggunakan fitur sekali dalam setahun terakhir adalah pengguna. Pelanggan yang membangun alur kerja di sekitarnya, menggunakannya dalam proses berulang, atau telah mengintegrasikannya melalui API adalah pihak yang bergantung padanya. Ini adalah profil risiko yang sepenuhnya berbeda.

Data penggunaan memberi tahu Anda siapa yang pernah menyentuhnya. Analitik produk Anda dapat menunjukkan akun mana yang telah menggunakan fitur tersebut dalam 90 hari terakhir, frekuensi penggunaan, dan apakah penggunaan meningkat atau menurun. Ini perlu tetapi belum cukup.

Data ketergantungan memberi tahu Anda siapa yang tidak bisa melepaskannya. CS mengetahui hal-hal yang tidak ditunjukkan oleh data produk: pelanggan mana yang menyebutkan fitur ini dalam QBR, mana yang pernah menanyakannya dalam tiket dukungan, mana yang telah melatih tim mereka menggunakannya. Inilah intelijen yang dibawa CS ke percakapan penghentian yang tidak dimiliki Product hanya dari metrik penggunaan.

Proses masukan CS pra-penghentian seharusnya terlihat seperti ini: Product berbagi kandidat penghentian dengan pimpinan CS. Pemimpin CS memiliki 5-7 hari kerja untuk meninjau catatan pelanggan, catatan QBR, dan riwayat dukungan, lalu mengembalikan daftar akun yang dikelompokkan berdasarkan risiko. Tingkat 1 (ketergantungan tinggi, ARR tinggi) memerlukan jangkauan personal proaktif dari CSM mereka sebelum email apa pun dikirimkan. Tingkat 2 (ketergantungan sedang) menerima email penghentian dengan tindak lanjut CSM dalam 48 jam. Tingkat 3 (ketergantungan rendah atau tidak ada) menerima email penghentian standar. Menjalankan tinjauan akun berisiko bersama dengan Sales sebelum komunikasi penghentian dikirim membantu mengidentifikasi akun Tingkat 1 mana yang juga memiliki percakapan ekspansi terbuka yang perlu dilindungi secara terpisah.

Klasifikasi ini hanya berfungsi jika CS memiliki akses ke data yang tepat. Penilaian dampak pelanggan memformalkan proses ini dengan membangun kerangka yang dapat diulang untuk mengukur akun mana yang paling terpapar perubahan produk apa pun, tidak hanya penghentian.

Apa arti "ketergantungan" dalam praktiknya:

• Fitur tersebut dirujuk dalam kriteria keberhasilan yang terdokumentasi
• Mereka menyebutkannya dalam QBR atau pemeriksaan kesehatan dalam 12 bulan terakhir
• Mereka memiliki integrasi API yang menggunakan fitur tersebut
• Mereka telah mengajukan tiket dukungan tentang fitur itu dalam 90 hari terakhir
• Skor kesehatan akun CS mereka memiliki korelasi dengan penggunaan fitur ini

Langkah 2: Menetapkan Jadwal Penghentian

Berapa banyak pemberitahuan yang cukup? Jawaban jujurnya adalah: tergantung pada seberapa bergantung akun yang terdampak dan seberapa mudah migrasinya. Riset pencegahan perpindahan pelanggan Gartner menemukan bahwa 60% pembeli perangkat lunak yang membatalkan kontrak melakukannya karena keputusan pembelian yang kemudian mereka sesali, dan migrasi fitur paksa tanpa pemberitahuan yang memadai adalah pemicu klasik penyesalan tersebut.

Kerangka awal yang berguna:

Tarik-ulur antara Product dan CS soal jadwal adalah hal yang wajar. Product ingin bergerak cepat: utang teknis memiliki biaya, dan semakin lama fitur yang dihentikan tetap aktif, semakin banyak upaya rekayasa yang dikonsumsinya. CS menginginkan lebih banyak waktu karena percakapan migrasi membutuhkan waktu, dan memaksa akun ARR tinggi ke dalam migrasi yang terkompresi menciptakan risiko perpindahan pelanggan.

Masukan CS dalam percakapan jadwal bukan hak veto. Tetapi ini adalah sinyal risiko yang diperlukan. Format yang tepat: "Berikut tiga akun yang kami yakini memiliki risiko perpindahan tertinggi dari penghentian ini, ARR mereka, tanggal pembaruan mereka, dan penilaian kami tentang kesulitan migrasi. Berdasarkan ini, kami merekomendasikan jendela 90 hari alih-alih 30 hari." Itu bukan meminta lebih banyak waktu karena perubahan itu sulit. Itu membuat argumen bisnis dengan ARR yang terlampir.

Perbedaan antara penghentian dan pemutusan keras juga penting. Pemberitahuan penghentian menyatakan: "Fitur ini tidak akan tersedia setelah [tanggal]." Pemutusan keras adalah tanggal penegakan aktual. Untuk akun dengan ketergantungan tinggi, pertimbangkan apakah pemberitahuan penghentian dan pemutusan keras perlu dipisahkan lebih dari periode pemberitahuan standar. Beberapa perusahaan menawarkan perpanjangan yang dinegosiasikan kepada akun enterprise, tetapi ini perlu ditangani dengan hati-hati (lihat anti-pola di bawah).

Langkah 3: Komunikasi, Apa, Kapan, dan Siapa

Siapa yang menyampaikan berita:

Untuk akun Tingkat 1 (ARR tinggi, ketergantungan tinggi), CSM menyampaikan berita dalam percakapan langsung: panggilan khusus, bukan email. CSM menelepon akun, menjelaskan situasinya, dan email penghentian menyusul sebagai konfirmasi tertulis dari apa yang telah dibahas. Pelanggan tidak boleh melihat email sebelum berbicara dengan CSM mereka.

Untuk akun Tingkat 2, email penghentian dikirim terlebih dahulu, diikuti oleh jangkauan CSM dalam 48 jam. Tugas CSM dalam tindak lanjut tersebut adalah memahami dampaknya dan memulai percakapan migrasi.

Untuk akun Tingkat 3, email penghentian adalah komunikasi utama. CS menangani pertanyaan yang masuk sesuai kebutuhan.

Apa yang termasuk dalam pesan:

• Fitur yang dihentikan, dijelaskan dengan jelas (bukan hanya nama internalnya)
• Alasannya, dalam bahasa yang mudah dipahami (lihat empat alasan di atas)
• Tanggal efektif, termasuk tanggal pemberitahuan penghentian dan tanggal pemutusan keras
• Apa yang menggantikannya, jika ada, dengan deskripsi jujur apakah penggantinya setara
• Dukungan migrasi apa yang tersedia: dokumentasi, sesi khusus, dukungan rekayasa untuk migrasi API
• Kepada siapa harus menghubungi jika ada pertanyaan

Apa yang tidak termasuk dalam pesan:

• Permintaan maaf yang menyiratkan keputusan tersebut salah ("Kami mohon maaf atas ketidaknyamanan yang mungkin ditimbulkan" menandakan penyesalan atas keputusan, bukan empati terhadap pelanggan)
• Jadwal yang tidak jelas ("suatu saat dalam beberapa bulan mendatang" tidak memberi pelanggan apa pun untuk direncanakan; mereka berhak mendapatkan tanggal yang spesifik)
• Alternatif yang tidak diminta yang tidak ditanyakan pelanggan ("Anda juga bisa menggunakan alat pelaporan baru kami!" terasa seperti upsell di tengah pengumuman negatif)
• Pembingkaian optimisme korporat ("Kami sangat antusias untuk menyederhanakan platform kami!" tidak akan diterima baik ketika pelanggan diminta untuk mengubah alur kerja mereka)

Template komunikasi untuk tiga skenario:

Skenario A: Fitur dihentikan dengan pengganti langsung "[Nama fitur] akan dihentikan pada [tanggal]. Kami telah membangun [pengganti] untuk memenuhi kebutuhan yang sama, dan kami percaya itu adalah fondasi yang lebih kuat untuk [kasus penggunaan inti]. [Pengganti] menangani [fungsi spesifik] dengan [cara spesifik]. Kami telah menyiapkan dokumentasi migrasi dan tim kami tersedia untuk sesi migrasi khusus. Silakan hubungi CSM Anda untuk menjadwalkannya."

Skenario B: Fitur dihentikan tanpa pengganti langsung "[Nama fitur] akan dihentikan pada [tanggal]. Fungsionalitas ini tidak digantikan oleh satu padanan tunggal. [Penjelasan jujur mengapa.] Berdasarkan cara tim Anda menggunakannya, kami percaya [solusi sementara atau pendekatan alternatif] mungkin dapat memenuhi kebutuhan inti Anda. CSM Anda akan menghubungi minggu ini untuk memahami situasi spesifik Anda dan memastikan Anda memiliki jalan ke depan."

Skenario C: Fitur dihentikan karena kepatuhan atau keamanan "[Nama fitur] akan dihentikan pada [tanggal]. Keputusan ini diperlukan oleh [regulasi/persyaratan keamanan] dan berlaku bagi semua pelanggan. Kami memahami bahwa ini memerlukan penyesuaian dari pihak Anda. [Jalur migrasi]. CSM Anda akan menghubungi untuk membantu Anda menavigasi transisi ini."

Langkah 4: Percakapan Migrasi

Ketika ada fitur pengganti: Jangan berasumsi bahwa pengganti lebih baik untuk setiap pelanggan. Katakan secara eksplisit: "Kemampuan baru menangani [X] secara berbeda. Bagi sebagian besar pelanggan ini adalah peningkatan, tetapi saya ingin memahami alur kerja spesifik Anda sebelum kita membahas migrasi." Pendekatan ini lebih jujur dan menghasilkan hasil migrasi yang lebih baik karena Anda mengidentifikasi kesenjangan sebelum pelanggan menemukannya. Panduan strategi adopsi fitur berlaku di sini. Memigrasikan pelanggan ke fitur pengganti memerlukan pendekatan adopsi terstruktur yang sama seperti meluncurkan fitur baru, bukan hanya pemberitahuan satu kali.

Ketika tidak ada pengganti langsung: CS dapat menawarkan tiga hal: dokumentasi solusi sementara, dukungan konfigurasi khusus, dan visibilitas peta jalan produk tentang apa yang sedang dibangun yang mungkin memenuhi kebutuhan mendasar di masa depan. Yang tidak dapat ditawarkan CS adalah janji bahwa penggantinya akan segera hadir, kecuali itu dikonfirmasi secara faktual di tingkat yang sesuai.

Ketika pelanggan mengatakan jalur migrasi tidak sesuai untuk kasus penggunaan mereka: Ini adalah percakapan produk, bukan hanya percakapan CS. Tugas CSM pada saat ini adalah menangkap kesenjangan spesifik dan mengeskalasinya ke Product: "Pelanggan kami di [perusahaan] memiliki ketergantungan pada [kemampuan spesifik] yang tidak tercakup oleh penggantinya. Inilah yang mereka butuhkan. Bisakah kita melakukan panggilan 30 menit dengan PM untuk mendiskusikannya?" Apakah hasilnya adalah akomodasi produk, jadwal yang dinegosiasikan, atau solusi sementara yang terdokumentasi adalah keputusan Product. Tetapi CSM-lah yang membawa hal itu ke hadapan orang-orang yang tepat.

Langkah 5: Manajemen Risiko Retensi

Zona merah: Akun yang bergantung pada fitur yang dihentikan dan berada dalam jendela pembaruan. Akun-akun ini perlu mendengar dari CSM mereka sebelum pemberitahuan penghentian dikirim, dan CSM memerlukan rencana retensi untuk masing-masing sebelum komunikasi eksternal apa pun terjadi. Edukasi pelanggan adalah kunci dalam rencana tersebut. Panduan migrasi yang menangani poin kebingungan yang paling umum mengurangi eskalasi dukungan secara signifikan selama jendela transisi.

Rencana retensi tidak harus rumit. Perlu menjawab: apa jalur migrasi akun tersebut, apa jadwalnya, siapa di sisi CS yang bertanggung jawab mendorongnya sampai selesai, dan apa eskalasi jika pelanggan memberi sinyal bahwa mereka mempertimbangkan penghentian sebagai alasan untuk tidak memperbarui?

Apa yang dibawa pimpinan CS ke Product sebelum penghentian yang menyentuh akun ARR teratas:

Sebelum penghentian diselesaikan, pimpinan CS harus mempresentasikan kepada Product: daftar peringkat 10 akun terdampak teratas berdasarkan ARR, tanggal pembaruan mereka, tingkat ketergantungan mereka, dan perkiraan kesulitan migrasi. Ini bukan permintaan veto. Ini adalah pengarahan risiko bisnis. Informasi tersebut mengubah perhitungan risiko tim Product tentang jadwal penghentian dan apakah akun tertentu memerlukan penanganan khusus.

Perpanjangan yang dinegosiasikan: Menawarkan akun ARR tinggi tertentu lebih banyak waktu dari jendela pemberitahuan standar bisa menjadi keputusan yang tepat. Tetapi itu perlu dikelola dengan hati-hati. Satu perpanjangan informal menetapkan preseden yang pada akhirnya akan ditemukan oleh semua akun terdampak lainnya. Jika Anda memperpanjang untuk satu akun, putuskan di tingkat kepemimpinan apakah perpanjangan tersebut tersedia untuk semua akun Tingkat 1 atau hanya akun ini, dan dokumentasikan keputusan tersebut.

Menyampaikan hasil retensi kembali ke Product: Setelah penghentian selesai, lacak apa yang terjadi pada akun yang terdampak. Berapa banyak yang berhasil bermigrasi? Berapa banyak yang berpindah? Berapa banyak yang memerlukan pengecualian atau negosiasi? Data tersebut termasuk dalam retrospektif dengan Product, dan harus menginformasikan proses untuk penghentian berikutnya, termasuk berapa banyak pemberitahuan yang sesuai dan seberapa awal masukan CS perlu terjadi. Riset HBR tentang retensi pelanggan berpendapat bahwa biaya kehilangan pelanggan yang tepat hampir selalu lebih tinggi dari yang terlihat dalam metrik perpindahan saja, menjadikan data retensi pasca-penghentian sebagai salah satu masukan paling kurang dihargai dalam perencanaan produk.

Anti-Pola

Menyembunyikan penghentian dalam catatan rilis dan berharap tidak ada yang menyadarinya. Beberapa pelanggan tidak akan menyadarinya selama berbulan-bulan. Tetapi pelanggan yang bergantung padanya akan langsung menyadarinya, dan mereka akan merasa terkejut karena tidak diberi peringatan sebelumnya. Pelanggan yang tidak menyadarinya akan baik-baik saja. Mereka yang menyadarinya dan tidak diberi tahu adalah risiko perpindahan Anda.

Menawarkan solusi sementara khusus yang harus didukung CS selamanya. Dalam percakapan migrasi, godaannya adalah menyelesaikan masalah segera pelanggan dengan solusi sementara yang hanya berfungsi untuk kasus spesifik mereka. Solusi sementara tersebut kemudian menjadi kewajiban dukungan tanpa batas waktu. Setiap solusi sementara yang ditawarkan CS dalam migrasi penghentian harus ditinjau oleh Product untuk skalabilitas. Jika memerlukan upaya CS yang berkelanjutan untuk dipelihara, itu bukan solusi sementara, melainkan akomodasi permanen yang tidak disetujui siapapun.

Memberikan perpanjangan batas waktu informal kepada pelanggan enterprise yang menciptakan preseden. "Kami akan tetap menyalakannya untuk Anda hingga akhir tahun kontrak Anda," yang dikatakan secara informal oleh CSM dalam panggilan retensi, menciptakan kewajiban yang belum disetujui Product, yang harus dipelihara rekayasa, dan yang akhirnya akan didengar oleh pelanggan lain dan diminta untuk diri mereka sendiri. Perpanjangan harus melalui pimpinan CS dan mendapatkan persetujuan eksplisit Product.

Membingkai penghentian sebagai "berita yang menggembirakan" dalam email komunikasi. Pelanggan yang diminta untuk mengubah alur kerja mereka tidak merasa antusias. Bahasa seperti "kami sangat senang untuk memajukan platform kami dengan menghentikan [fitur]" menandakan ketidaksesuaian antara cara vendor melihat perubahan dan cara pelanggan mengalaminya. Sampaikan dengan lugas. Beritanya adalah apa adanya.

Daftar Periksa Penghentian Bersama CS-Product

Sebelum keputusan penghentian diselesaikan:

• CS telah meninjau data penggunaan dan mengembalikan penilaian risiko ketergantungan untuk akun yang terdampak
• Akun dalam jendela pembaruan telah diidentifikasi dan ditandai
• Pimpinan CS telah mempresentasikan akun risiko ARR teratas kepada Product
• Jadwal penghentian telah ditetapkan dengan masukan CS tentang kesulitan migrasi

Sebelum komunikasi eksternal dikirimkan:

• Akun Tingkat 1 telah dihubungi oleh CSM mereka dalam percakapan langsung
• Template komunikasi yang disetujui sudah siap dan telah ditinjau oleh Product dan Legal
• Pengarahan CSM telah selesai: setiap CSM mengetahui alasan penghentian, jalur migrasi, dan bahasa yang disetujui
• Jalur eskalasi telah ditetapkan untuk akun yang menolak jalur migrasi

Selama jendela migrasi:

• Check-in mingguan antara CS dan Product mengenai kemajuan migrasi untuk akun Tingkat 1
• Setiap kesenjangan produk yang muncul dalam percakapan migrasi telah dieskalasikan ke Product
• Permintaan perpanjangan dari akun enterprise telah ditinjau oleh pimpinan CS dan mendapatkan persetujuan eksplisit Product

Setelah penghentian selesai:

• Hasil retensi untuk semua akun yang terdampak telah didokumentasikan
• Retrospektif telah dilakukan bersama CS dan Product untuk menangkap apa yang berhasil dan apa yang tidak
• Peningkatan proses untuk penghentian di masa depan telah disepakati dan didokumentasikan

Pertanyaan siapa yang memiliki perubahan yang menghadap pelanggan dan catatan rilis terhubung langsung dengan daftar periksa ini. Kepemilikan yang jelas atas hasil komunikasi adalah yang membuat setiap langkah terlaksana tepat waktu alih-alih jatuh ke celah antara CS dan Product. Dan untuk akun di mana penghentian mengungkap pola kebutuhan yang tidak terpenuhi yang lebih luas, proses menutup lingkaran umpan balik adalah tempat wawasan tersebut pergi untuk menghasilkan peningkatan permanen dalam cara keputusan produk dibuat.

Panduan Penghentian 5 Langkah

Panduan Penghentian 5 Langkah menamai lima fase proses penonaktifan fitur bersama CS-Product. Langkah-langkah berjalan secara berurutan, dan melewati salah satu dari mereka adalah sumber paling umum dari perpindahan pelanggan penghentian yang dapat dicegah.

Langkah 1: Identifikasi ketergantungan. Sebelum jadwal penghentian ditetapkan, CS meninjau data penggunaan dan catatan pelanggan untuk membedakan pengguna dari pihak yang bergantung. Mengembalikan daftar akun yang dikelompokkan berdasarkan risiko: Tingkat 1 (ketergantungan tinggi, ARR tinggi), Tingkat 2 (ketergantungan sedang), Tingkat 3 (ketergantungan rendah atau tidak ada). Langkah ini harus terjadi sebelum komunikasi eksternal direncanakan.

Langkah 2: Penetapan jadwal. CS dan Product menyepakati jendela pemberitahuan menggunakan matriks ketergantungan-migrasi (30 hari untuk migrasi mudah dengan ketergantungan rendah; 90-120 hari untuk akun terintegrasi API dengan ketergantungan tinggi; 120+ hari dengan jadwal yang dinegosiasikan untuk ketergantungan alur kerja kritis). Masukan CS bukan hak veto. Ini adalah sinyal risiko dengan ARR yang terlampir.

Langkah 3: Desain komunikasi. Tiga template berbeda untuk tiga skenario (pengganti ada, tidak ada pengganti, penghentian berbasis kepatuhan). Akun Tingkat 1 menerima panggilan CSM langsung sebelum email dikirim. Akun Tingkat 2 menerima email diikuti oleh jangkauan CSM dalam 48 jam. Akun Tingkat 3 menerima email standar. Template ditinjau oleh Product dan Legal sebelum ada pelanggan yang melihatnya.

Langkah 4: Percakapan migrasi. Dukungan migrasi per akun, dengan jalur eskalasi yang jelas ketika jalur migrasi tidak mencakup kasus penggunaan spesifik pelanggan. Setiap solusi sementara yang ditawarkan harus ditinjau oleh Product untuk skalabilitas sebelum menjadi kewajiban dukungan permanen.

Langkah 5: Pelacakan retensi dan retrospektif. Pasca-penghentian: dokumentasikan berapa banyak akun yang terdampak berhasil bermigrasi, berpindah, atau memerlukan pengecualian yang dinegosiasikan. Jalankan retrospektif bersama CS dan Product. Sampaikan hasilnya kembali ke dalam proses untuk penghentian berikutnya.

Analisis Rework: Kegagalan proses yang paling konsisten dalam penonaktifan fitur bukan pada template komunikasi atau panjang pemberitahuan. Melainkan pada Langkah 1. Perusahaan yang melewati langkah identifikasi ketergantungan memperlakukan semua akun yang terdampak dengan cara yang sama, yang berarti akun terintegrasi API dengan ARR tinggi menerima email 30 hari yang sama dengan yang diterima pengguna kasual. Data tentang hal ini jelas: perusahaan yang memberi tahu pelanggan dengan pemberitahuan 90+ hari melihat tingkat perpindahan 3,2x lebih rendah di antara akun yang terdampak dibandingkan dengan pemberitahuan 30 hari (data benchmark ChurnZero). Tetapi panjang pemberitahuan hanyalah sebagian dari hasilnya. Akun yang menerima panggilan langsung proaktif dari CSM mereka sebelum email tiba memiliki hasil retensi yang jauh lebih baik dibandingkan mereka yang mendapatkan email lebih dulu, terlepas dari panjang pemberitahuan. Langkah 1 adalah yang memberi tahu Anda akun mana yang memerlukan panggilan. Tanpanya, setiap akun mendapatkan email.

Pertanyaan yang Sering Diajukan

Apa itu Panduan Penghentian 5 Langkah?

Panduan Penghentian 5 Langkah adalah proses bersama CS-Product untuk menonaktifkan fitur tanpa kehilangan akun yang bergantung padanya. Lima langkahnya adalah: identifikasi ketergantungan (sebelum jadwal ditetapkan), penetapan jadwal (dengan masukan CS tentang kesulitan migrasi), desain komunikasi (tiga template, dikelompokkan berdasarkan ketergantungan akun), percakapan migrasi (dengan jalur eskalasi yang jelas untuk kesenjangan), dan pelacakan retensi dengan retrospektif pasca-penghentian. Organisasi yang menggunakan proses penghentian formal dengan kepemilikan bersama CS-Product melaporkan hasil retensi 44% lebih baik di antara akun yang terdampak dibandingkan yang menggunakan komunikasi ad hoc, menurut data pengalaman pelanggan TSIA.

Berapa banyak pemberitahuan yang harus diterima pelanggan sebelum fitur dihentikan?

Panjang pemberitahuan harus sesuai dengan tingkat ketergantungan dan kesulitan migrasi. Minimumnya adalah 30 hari untuk fitur dengan ketergantungan rendah dan migrasi mudah. Akun dengan ketergantungan tinggi (yang memiliki integrasi API atau penggunaan kritis untuk alur kerja) membutuhkan 90 hingga 120 hari. Akun dengan proses bisnis kritis yang dibangun di sekitar fitur tersebut mungkin membutuhkan 120+ hari dan jadwal yang dinegosiasikan. Perusahaan yang memberi tahu pelanggan dengan pemberitahuan 90+ hari melihat tingkat perpindahan 3,2x lebih rendah di antara akun yang terdampak dibandingkan pemberitahuan 30 hari, menurut data benchmark ChurnZero. Cara paling andal untuk menetapkan jadwal yang tepat adalah menyelesaikan langkah identifikasi ketergantungan sebelum jadwal diselesaikan.

Mengapa sebagian besar proses penghentian fitur menghasilkan perpindahan pelanggan?

Sebagian besar perpindahan pelanggan akibat penghentian dapat dicegah dan berasal dari satu kegagalan struktural: CS dilibatkan pada waktu yang sama dengan pelanggan diberitahu, atau setelahnya. Hanya 38% tim produk yang secara formal melibatkan CS sebelum menyelesaikan jadwal penghentian, menurut studi State of Product Management ProductBoard. Ketika CS mengetahui tentang penghentian di minggu yang sama dengan pelanggan, CSM tidak memiliki bahasa yang disetujui, tidak ada panduan migrasi, dan tidak ada cara untuk mengidentifikasi akun mana yang berisiko paling tinggi sebelum panggilan eskalasi pertama tiba. Panduan Penghentian 5 Langkah membalik ini: CS dilibatkan sebelum keputusan diselesaikan, akun yang dikelompokkan berdasarkan risiko diidentifikasi sebelum komunikasi eksternal apa pun dikirim, dan CSM mendapat pengarahan sebelum percakapan pelanggan apa pun terjadi.

Apa perbedaan antara pengguna dan pihak yang bergantung untuk tujuan penghentian fitur?

Pengguna adalah akun mana pun yang telah menyentuh fitur tersebut dalam 90 hari terakhir. Pihak yang bergantung adalah akun yang telah membangun alur kerja di sekitarnya, menggunakannya dalam proses yang berulang, atau mengintegrasikannya melalui API. Ini adalah profil risiko yang sepenuhnya berbeda untuk penghentian. Analitik produk mengidentifikasi pengguna; pengetahuan CS mengidentifikasi pihak yang bergantung. Penanda ketergantungan adalah: fitur muncul dalam kriteria keberhasilan yang terdokumentasi, akun menyebutnya dalam QBR dalam 12 bulan terakhir, ada integrasi API yang menggunakannya, atau ada tiket dukungan tentangnya dalam 90 hari terakhir. Langkah identifikasi ketergantungan menggabungkan kedua sumber data untuk menghasilkan daftar akun yang dikelompokkan berdasarkan risiko.

Bagaimana CSM harus mengomunikasikan penonaktifan fitur kepada akun ARR tinggi?

Untuk akun Tingkat 1 (ARR tinggi, ketergantungan tinggi), CSM menyampaikan berita dalam percakapan langsung sebelum email penghentian dikirim. Pelanggan tidak boleh melihat email sebelum berbicara dengan CSM mereka. Percakapan mencakup: apa yang dihentikan dan kapan, alasannya dalam bahasa yang mudah dipahami, apa yang menggantikannya (jika ada, dengan penilaian jujur apakah penggantinya setara), dan dukungan migrasi apa yang tersedia. Email tindak lanjut berfungsi sebagai konfirmasi tertulis dari apa yang telah dibahas. Urutan ini (panggilan langsung terlebih dahulu, email kedua) adalah yang membedakan penghentian yang terkelola dari notifikasi krisis.

Apa yang harus dilakukan CS ketika pelanggan mengatakan jalur migrasi tidak sesuai untuk kasus penggunaan mereka?

Eskalasikan ke Product segera dengan spesifikasi: perusahaan, ARR, kemampuan spesifik yang tidak tercakup oleh pengganti, dan apa yang dibutuhkan pelanggan. Jangan menjanjikan akomodasi produk atau jadwal. Itu adalah keputusan Product. Tugas CSM adalah membawa orang-orang yang tepat ke dalam percakapan sebelum pelanggan membuat keputusan pembaruan berdasarkan masalah yang tidak dapat diselesaikan CS sendirian. Setiap solusi sementara yang ditawarkan CS dalam percakapan migrasi harus ditinjau oleh Product untuk skalabilitas: jika memerlukan upaya CS yang berkelanjutan untuk dipelihara, itu bukan solusi sementara, melainkan akomodasi permanen yang tidak disetujui siapapun secara formal.

Pelajari Lebih Lanjut

• Cara CS Mengomunikasikan Peta Jalan Produk Tanpa Berlebihan Berjanji
• Menutup Lingkaran Umpan Balik dengan Pelanggan
• Siapa yang Memiliki Perubahan yang Menghadap Pelanggan (Catatan Rilis, Dalam Aplikasi)
• Masalah 'Kami Membangunnya, Tidak Ada yang Menggunakannya'
• Penilaian Dampak Pelanggan untuk Keputusan Produk
• Manajemen Akun Berisiko
• Tinjauan Akun Berisiko Bersama
• Strategi Adopsi Fitur