Kejayaan Pelanggan & Penjajaran Produk

Ketidakselarasan CS-Produk hampir tidak pernah menyatakan dirinya dengan jelas. Tiada satu ketika di mana VP CS menghantar e-mel berkata "kita tidak sejajar dengan Produk" atau di mana Head of Product memanggil mesyuarat untuk membincangkan gelung maklum balas yang tidak wujud. Sebaliknya, ia terkumpul: dalam aduan yang sama muncul berulang kali dalam QBR demi QBR, dalam angka penggunaan ciri yang tidak pernah disiasat dengan teliti, dalam seorang CSM yang telah berhenti menghantar maklum balas kerana mereka tidak pernah melihatnya membawa sebarang perubahan. Sekiranya anda baru kepada topik ini, apa itu penjajaran CS-Produk memberikan konteks model operasi yang memudahkan tanda-tanda ini ditafsirkan.

Menjelang seseorang menamai corak itu sebagai ketidakselarasan, kerosakan sudah pun terserlah dalam baris NRR.

Lapan tanda amaran di bawah adalah corak, bukan hukuman. Melihat satu atau dua daripadanya tidak bermakna organisasi itu rosak. Melihat lima atau enam bermakna model operasi memerlukan pembaikan sebenar, dan menunggu suku tahun lagi untuk menanganinya akan memberi kesan yang mahal. Setiap tanda disertai dengan gambaran praktikalnya, sebab ia berlaku, dan satu langkah pertama yang konkrit: sesuatu yang boleh anda lakukan minggu ini, bukan suku tahun hadapan.

Cara Menggunakan Artikel Ini

Ambil setiap tanda amaran dan semak terhadap realiti semasa anda, bukan terhadap bagaimana anda mahu keadaan berfungsi, dan bukan terhadap bagaimana ia berfungsi ketika segalanya berjalan lancar. Versi jujur latihan ini berguna. Versi bercita-cita tinggi tidak.

Jika anda seorang VP CS yang membaca ini bersama Head of Product anda (kes penggunaan yang dimaksudkan), tandakan tanda-tanda yang anda kenali dari pengalaman anda sendiri tanpa menganggapnya milik pasukan tertentu. Matlamatnya adalah diagnosis bersama, bukan peruntukan salah. Kesemua lapan tanda menggambarkan kegagalan reka bentuk sistem, bukan kegagalan prestasi individu.

Fakta Utama: Corak Ketidakselarasan dalam SaaS Pasaran Pertengahan

74% akaun yang berhenti berlangganan atas sebab berkaitan produk pernah menyuarakan kebimbangan yang sama kepada CSM mereka sebelum meninggalkan syarikat. Corak ketidakselarasan kelihatan sebelum impak hasil berlaku (Gainsight).

Ciri-ciri yang dibina tanpa input CS selepas jualan mempunyai kadar penggunaan ciri 90 hari yang purata 30-40% lebih rendah berbanding ciri yang dibangunkan dengan maklum balas CS berstruktur (ProductPlan).

CSM tanpa proses maklum balas berstruktur menghabiskan kira-kira 23% masa mereka untuk tugasan maklum balas produk, dua kali ganda kadar CSM di organisasi dengan saluran VoC yang ditakrifkan (TSIA).

Tanda Amaran 1: CSM Menerima Aduan yang Sama Selama Lebih Daripada Dua Suku Tahun Berturut-turut

Dipetik: "Aduan yang muncul merentasi 12 akaun selama enam suku tahun kelihatan seperti 12 aduan individu dalam saluran Slack. Ia tidak muncul secara automatik sebagai '12 akaun mewakili $480K ARR, 4 daripadanya menjelang pembaharuan dalam S3, semuanya menyebut had yang sama.' Tanpa pengagregatan berwajaran ARR, Produk tidak dapat melihat corak yang dialami CS setiap minggu."

Rupanya begini: Tarik nota persediaan QBR dari enam bulan lepas. Cari frasa berulang dalam transkrip standup CSM. Buka log peningkatan isu. Jika tema yang sama (jurang integrasi tertentu, had pelaporan, aliran kerja yang memerlukan terlalu banyak langkah manual) muncul merentasi beberapa CSM, beberapa akaun, dan beberapa suku tahun tanpa pergerakan ketara di pihak produk, anda sedang menyaksikan ketidakselarasan dalam tindakan.

Para CSM tahu ia berulang. Mereka menyebutnya dalam mesyuarat pasukan. Sebahagian telah menyerahkannya sebagai item maklum balas. Corak berterusan kerana tiada mekanisme yang menukar isyarat berulang kepada tekanan pengutamaan.

Sebabnya berlaku: Tiada penghalaan maklum balas berstruktur, atau penghalaan maklum balas tanpa pemberat ARR. Aduan yang muncul dalam nota QBR 12 akaun selama enam bulan kelihatan seperti 12 aduan individu dalam saluran Slack. Ia tidak muncul secara automatik sebagai "12 akaun mewakili $480K ARR, 4 daripadanya menjelang pembaharuan dalam S3, semuanya menyebut had yang sama." Tanpa pandangan terkumpul itu, Produk tidak dapat melihat corak yang dialami CS. Panduan program VoC Gartner jelas mengenai perkara ini: data VoC tidak berstruktur kurang boleh diambil tindakan berbanding tiada data VoC langsung, kerana ia mewujudkan rasa liputan yang palsu sambil secara sistematik menyelewengkan pengutamaan. Model pengukuran maklum balas berwajaran ARR adalah penyelesaiannya: ia menukar volum kepada isyarat yang bersedia untuk pengutamaan.

Langkah pertama: Tarik nota CSM dan dokumen persediaan QBR dari dua suku tahun lepas. Hitung setiap sebutan tema berulang utama. Tambah ARR akaun di mana setiap tema muncul. Bawa dokumen itu (tema, kiraan, pendedahan ARR, pembaharuan yang akan datang) ke sinkronisasi CS-Produk berikutnya. Itulah format yang menukar corak daripada "sesuatu yang CSM kecewa" kepada "risiko pengekalan $480K dengan nama."

Tanda Amaran 2: CSM Tidak Dapat Menjawab "Bila X Akan Tiba?" Tanpa Meneka

Rupanya begini: Seorang pelanggan bertanya kepada CSM mereka: "Anda menyebut dalam QBR terakhir kita bahawa peningkatan had kadar API akan datang tahun ini. Adakah anda mempunyai jadual masa?" CSM membuka tab pelayar baru dan mencari halaman Notion dalaman yang tidak dikemas kini sejak S4. Mereka menghantar Slack ke #cs-product-feedback. Mereka menyemak e-mel untuk dek pelan hala tuju produk terkini. Tiga puluh minit kemudian, mereka membalas dengan "Saya sedang menghubungi pasukan dan akan kembali kepada anda," yang mereka tahu akan menghasilkan perbualan yang janggal tiga hari kemudian apabila mereka terpaksa berkata "ia ada dalam backlog tetapi tidak dijadualkan."

Senario ini berlaku berdozen kali sehari dalam organisasi yang tidak sejajar. CSM itu bukan tidak cekap; mereka beroperasi tanpa sumber maklumat yang boleh dipercayai.

Sebabnya berlaku: Pelan hala tuju produk tidak dikongsi dengan CS pada jadual yang boleh diramal, atau dikongsi terlalu lewat (sehari sebelum ia disampaikan kepada pelanggan), atau dikongsi dalam format yang tidak diterjemahkan ke dalam bahasa pelanggan. CSM dijangka menyimpan komitmen pelan hala tuju dalam perbualan dengan pelanggan tetapi tidak diberi maklumat untuk melakukannya dengan meyakinkan.

Langkah pertama: Bersetuju dengan tetingkap pra-pengumuman dua minggu. Sebelum sebarang kemas kini pelan hala tuju, nota keluaran, atau surat berita produk disampaikan kepada pelanggan, CS mendapat taklimat. Bukan spesifikasi kejuruteraan penuh, tetapi ringkasan satu perenggan: apa yang akan datang, bila, dan masalah apa yang ia selesaikan. Tetingkap dua minggu itu yang menukar CSM daripada orang yang meneka pelan hala tuju kepada orang yang dapat menetapkan jangkaan yang tepat. Semak format pelan hala tuju awam berbanding peribadi berbanding berpintu untuk memilih pendekatan komunikasi yang betul.

Tanda Amaran 3: Penggunaan Ciri Secara Konsisten Rendah pada 90 Hari Selepas Pelancaran

Dipetik: "ProductPlan mendapati bahawa ciri-ciri yang dibina tanpa input CS selepas jualan mempunyai kadar penggunaan ciri 90 hari yang purata 30-40% lebih rendah berbanding ciri yang dibangunkan dengan maklum balas CS berstruktur. Penggunaan yang rendah bukan masalah pemasaran. Ia adalah isyarat ketidakselarasan yang dapat dikesan kembali kepada sama ada CS membentuk pembinaan dan dilengkapi untuk memacu penggunaan sebelum pelancaran." (ProductPlan, 2024)

Rupanya begini: Produk menghantar keluaran besar. Komunikasi pelancaran dikeluarkan. Para CSM melihatnya dalam log perubahan pada masa yang sama dengan pelanggan. Enam minggu kemudian, analitik penggunaan menunjukkan 12% akaun yang layak telah menggunakan ciri tersebut. Retrospektif selepas pelancaran sebahagian besarnya mengenai pemasaran dan pemesejan. CS tidak berada dalam bilik.

Sebabnya berlaku: CS tidak terlibat dalam membentuk ciri semasa pembangunan, jadi CSM tidak memahaminya cukup baik untuk mengkontekstualisasikannya kepada pelanggan. Mereka bukan sebahagian daripada beta, jadi mereka tidak melihatnya cukup awal untuk menyediakan pendekatan penggunaan. Mereka menerima nota keluaran pada masa yang sama dengan semua orang lain, yang bermakna soalan pelanggan pertama yang mereka terima mengenai ciri itu juga merupakan kali pertama mereka berfikir dengan teliti tentang cara menjawabnya.

Penggunaan ciri 90 hari yang secara konsisten rendah adalah petunjuk lewat ketidakselarasan semasa pembangunan. Jika CS terlibat lebih awal, dalam beta, dalam taklimat pra-pelancaran, dalam memahami kesakitan pelanggan tertentu yang ditangani oleh ciri tersebut, penggunaan akan lebih tinggi kerana pasukan yang paling dekat dengan pelanggan akan dilengkapi untuk memacu ia.

Langkah pertama: Tambah CS kepada senarai semak kesediaan pelancaran sebelum keluaran seterusnya keluar dari beta. Satu item baris: "CS diberi taklimat dan bersedia untuk menyokong penggunaan." Ini memerlukan sesi kerja pra-pelancaran di mana PM membimbing pasukan CS melalui ciri tersebut, menjelaskan masalah pelanggan yang ia selesaikan, dan menjawab soalan yang dijangka CSM akan terima daripada pelanggan. Sesi itu tidak perlu lama, 45 minit untuk kebanyakan ciri. Tetapi ia mengubah trajektori penggunaan kerana CSM yang melancarkan ciri tersebut bersedia dan bukannya berimprovisasi. Menjalankan program beta pelanggan dengan input CS mengenai pemilihan peserta menutup jurang ini di sumbernya, sebelum kesediaan pelancaran menjadi kecemasan.

Tanda Amaran 4: Backlog Permintaan Ciri Mengandungi Item yang Lebih Daripada Dua Tahun Lamanya

Rupanya begini: Buka backlog produk. Tapis mengikut "diminta pelanggan." Isih mengikut tarikh dicipta. Jika item tertua adalah lebih daripada 24 bulan lamanya dan tiada kemas kini status, tiada alasan penolakan, dan tiada petanda bahawa sesiapa pun telah menyemaknya sejak ia diserahkan, backlog itu adalah perkuburan dan bukannya alat pengutamaan.

Masalahnya bukan bahawa permintaan lama ditolak. Itu adalah perkara yang sangat normal. Masalahnya adalah ia berterusan tanpa resolusi, terkumpul dengan cara yang memberitahu CSM dan pelanggan bahawa menyerahkan maklum balas tidak memberi kesan.

Sebabnya berlaku: Tiada proses triaj, tiada pemberat ARR, tiada mekanisme untuk menutup gelung maklum balas dengan pelanggan yang pada mulanya meminta. Permintaan bertimbun dalam sistem backlog yang digunakan, dan backlog menjadi terlalu besar dan terlalu lapuk untuk disemak dengan bermakna. Pasukan produk yang pernah mencuba untuk melalui backlog satu kali tahu pengalamannya: separuh permintaan adalah dari akaun yang sejak itu telah meninggalkan syarikat, sepertiga adalah untuk ciri yang sudah pun dibina (dalam bentuk berbeza), dan selebihnya adalah samar-samar mengenai apa yang sebenarnya diperlukan oleh pelanggan.

Langkah pertama: Jadualkan sesi triaj bersama CS-Produk yang tertumpu khusus pada 20% item backlog yang diminta pelanggan yang paling lama. Untuk setiap item: sahkan sama ada akaun yang meminta masih aktif (jika tidak, arkibkan), semak sama ada keupayaan serupa wujud (jika ada, tutup dengan nota), dan sama ada pindahkan ke pertimbangan aktif atau tolak secara rasmi dengan alasan satu ayat. Tutup gelung maklum balas dengan mana-mana akaun aktif yang pada mulanya meminta item tersebut. Sesi ini tidak perlu berterusan. Ia adalah tindakan pembersihan yang menjadikan backlog boleh digunakan semula.

Tanda Amaran 5: Keputusan Produk Merujuk "Maklum Balas Pelanggan" tetapi Kepimpinan CS Tidak Dapat Mengenal Pasti Sumbernya

Rupanya begini: Dalam semakan pelan hala tuju produk, seorang PM membentangkan keutamaan suku tahun seterusnya. Satu item dirangka sebagai "pelanggan telah secara konsisten meminta integrasi Slack asli." VP CS berfikir: pelanggan mana? Dari segmen mana? Bila? Adakah ini muncul melalui CSM, atau melalui perbualan langsung PM-ke-pelanggan yang memintas saluran CS sepenuhnya? Mereka tidak bertanya soalan itu dengan lantang kerana ia akan terasa seperti mencabar pertimbangan PM dalam forum awam. Tetapi mereka membuat nota mental bahawa mereka tidak tahu dari mana ini datang.

Sebabnya berlaku: Laluan maklum balas ad hoc (perbualan langsung PM-ke-pelanggan, penyerahan jualan, perbualan persidangan) memintas saluran CS berstruktur sepenuhnya. Laluan tidak formal ini bukan semestinya buruk; PM yang bercakap terus dengan pelanggan adalah baik. Masalahnya adalah apabila perbualan tersebut menjadi input utama kepada keputusan pelan hala tuju tanpa CS mempunyai keterlihatan atau keupayaan untuk mengesahkan terhadap portfolio akaun mereka. Ini mencerminkan versi hulu masalah: apa yang rosak dalam penjajaran Jualan-CS apabila penyerahan adalah ad hoc.

Langkah pertama: Bersetuju dengan satu sumber kebenaran untuk atribusi maklum balas pelanggan. Setiap keutamaan pelan hala tuju harus dapat dikesan kepada rekod maklum balas bertag dan berwajaran ARR dengan sumber (diserahkan CS, dijumpai PM, ditandakan jualan) dan senarai akaun. Ini tidak memerlukan penghapusan perbualan informal PM-ke-pelanggan. Ia memerlukan merakamnya di tempat yang sama seperti semua yang lain supaya CS dapat melihat gambaran penuh dan mengesahkan sama ada corak itu adalah wakil.

Tanda Amaran 6: CS dan Produk Mempunyai Definisi Berbeza tentang Permintaan Pelanggan "Keutamaan Tinggi"

Rupanya begini: Selepas sinkronisasi CS-Produk, kedua-dua pihak berlepas dengan fikiran mereka telah bersetuju dengan keutamaan. Dua minggu kemudian, seorang CSM meningkatkan isu permintaan sebagai "kritikal: $220K pembaharuan dalam 45 hari, akaun mengancam untuk berhenti berlangganan atas sebab ini." PM yang menerima peningkatan isu menambahkannya ke backlog sebagai "keutamaan sederhana: satu akaun, kes penggunaan khusus." Kedua-dua respons adalah rasional dari sudut pandangan masing-masing. Tetapi mereka membuat keputusan pengutamaan dari rangka kerja yang sama sekali berbeza.

Sebabnya berlaku: CS melihat konteks hubungan (jadual pembaharuan, skor kesihatan akaun, kestabilan penyokong dalaman, ancaman persaingan). Produk melihat kekerapan ciri (berapa banyak akaun yang telah meminta, betapa lazimnya kes penggunaan itu muncul). Kedua-dua adalah input yang sah, tetapi tanpa rubrik pengutamaan yang dikongsi, setiap pihak menerapkan heuristik mereka sendiri secara bebas dan mencapai kesimpulan yang berbeza.

Langkah pertama: Bersetuju dengan rubrik pemarkahan berwajaran ARR untuk maklum balas sebelum semakan suku tahun seterusnya. Versi mudah: (Bilangan akaun yang meminta x Purata ARR akaun yang meminta x Pengganda keperluan mendesak) = Skor keutamaan. Pengganda keperluan mendesak adalah 2x jika mana-mana akaun yang meminta mempunyai pembaharuan dalam 90 hari dan telah menyenaraikan ini sebagai faktor pembaharuan, 1.5x jika ia adalah isyarat risiko tanpa pembaharuan tertentu, 1x sebaliknya. Ia tidak perlu rumit. Ia perlu dikongsi, supaya "keutamaan tinggi" membawa makna yang sama dalam mesyuarat pasukan CS seperti dalam sesi perancangan produk.

Tanda Amaran 7: Program Beta Diisi oleh Sesiapa yang Sukarela, Bukan Berdasarkan Kesesuaian Strategik

Rupanya begini: Produk mengumumkan beta untuk ciri baru. Komunikasi dihantar ke senarai luas: sesiapa yang berminat boleh mendaftar. Dua puluh akaun mendaftar. Mereka cenderung menjadi yang paling canggih dari segi teknologi, paling terlibat, paling sanggup melabur masa dalam program akses awal. Ciri tersebut dihantar. Penggunaan sihat dalam 20 akaun itu. Ketersediaan am dilancarkan, dan penggunaan dalam pangkalan yang lebih luas adalah mendatar.

Sebabnya berlaku: Pengrekrutan beta didorong oleh produk tanpa konteks portfolio akaun CS. Akaun yang sukarela bukan semestinya akaun yang maklum balas mereka akan paling mengasah ciri tersebut. Mereka adalah akaun yang membalas jemputan beta. Peserta beta yang paling berharga sering kali adalah akaun yang telah mengalami masalah tertentu yang ditangani oleh ciri tersebut, yang mewakili ICP teras, dan yang mempunyai hubungan CSM yang cukup kuat untuk menghasilkan maklum balas yang jujur dan bukannya galakan yang sopan. Model pengurusan tahap akses awal memberikan CS cara berstruktur untuk mengenal pasti dan mengurus peserta bernilai tinggi tersebut.

Langkah pertama: Tambah penapis CS kepada pengrekrutan beta sebelum keluaran seterusnya. Sebelum sebarang jemputan beta dihantar, CS mengesahkan untuk setiap akaun yang dicadangkan: adakah akaun ini mewakili kes penggunaan yang direka untuk ditangani oleh ciri tersebut? Adakah hubungan CSM cukup kuat untuk mendapatkan maklum balas yang jujur? Adakah kapasiti operasi akaun untuk mengambil bahagian dalam beta kini mencukupi? Penapis itu tidak menambah banyak masa kepada proses, dan ia mengubah kualiti kohort beta secara dramatik.

Tanda Amaran 8: NRR Mendatar Sementara Kelajuan Penghantaran Ciri Tinggi

Dipetik: "McKinsey mengenal pasti kelajuan penghantaran ciri tanpa kualiti isyarat sebagai jurang penentu antara syarikat SaaS dengan NRR yang berkembang dan mereka yang mempunyai pengekalan mendatar atau merosot, walaupun kedua-duanya menghantar pada kelajuan yang setanding. Menghantar perkara yang betul lebih penting daripada menghantar dengan cepat, dan 'betul' hanya boleh diketahui melalui risikan CS berstruktur." (McKinsey, Customer Success 2.0)

Rupanya begini: Produk menghantar secara berterusan: keluaran bulanan, keupayaan baru, pelan hala tuju produk yang penuh dan dilaksanakan dengan baik. Pasukan kejuruteraan adalah produktif dan semangat adalah tinggi. Tetapi apabila pasukan CS menyemak trend NRR, ia mendatar atau merosot. Kadar peralihan pelanggan stabil, pengembangan tidak bertambah baik, dan ciri-ciri yang dihantar tidak kelihatan menggerakkan penanda pengekalan. Strategi penggunaan ciri merangkumi cara mendorong penyerapan keluaran sedia ada sementara gelung maklum balas diperbaiki.

Sebabnya berlaku: Usaha pembinaan terputus dari pemacu pengekalan dan pengembangan. Produk menyelesaikan hipotesis pengutamaan sendiri, dan menyelesaikannya dengan baik, tetapi hipotesis tersebut tidak berasas pada apa yang CS lihat sebagai kesakitan pelanggan yang sebenarnya memacu kadar peralihan pelanggan dan menyekat pengembangan. Kelajuan penghantaran ciri tanpa kualiti isyarat adalah produktif dari segi operasi dan tidak berkesan dari segi pengekalan. Penyelidikan customer success 2.0 McKinsey mengenal pasti dengan tepat ketidaksamaan ini sebagai jurang penentu antara syarikat dengan NRR yang berkembang dan mereka yang mempunyai pengekalan mendatar atau merosot, walaupun kedua-duanya menghantar pada kelajuan yang setanding.

Langkah pertama: Jalankan retrospektif mengenai enam keluaran terakhir. Untuk setiap satu, petakan kepada kesakitan pelanggan yang bersumber CS atau peluang pengembangan: bolehkah anda mengesan keluaran ini kepada item maklum balas bertag dari portfolio akaun CSM? Jika kurang daripada separuh daripada enam keluaran terakhir dapat dipetakan dengan jelas kepada isyarat yang bersumber CS, anda sedang membina dari hipotesis dan bukannya dari risikan lapangan. Output retrospektif bukan salah. Ia adalah titik data yang menunjukkan kepada Produk di mana jurang isyarat berada dan CS di mana penghalaan maklum balas gagal.

Benang Merah yang Menghubungkan Semuanya

Kesemua lapan tanda menunjuk kepada punca akar yang sama: CS dan Produk beroperasi dalam gelung maklumat yang berasingan tanpa penyerahan berstruktur antara mereka. Isyarat yang dilihat CS di lapangan (aduan berulang, akaun berisiko, peluang pengembangan yang memerlukan komitmen pelan hala tuju) tidak sampai dalam keputusan produk dalam bentuk yang mengubahnya. Dan isyarat yang dijana Produk (keluaran yang akan datang, alasan pengutamaan, perubahan pelan hala tuju) tidak sampai ke tangan CS pada masa yang berguna dalam perbualan pelanggan. Penyelidikan jabat tangan penting TSIA merangka ini sebagai masalah struktur dengan penyelesaian struktur: jabat tangan antara dua fungsi ini perlu diformalkan, bukan diserahkan kepada hubungan peribadi atau inisiatif individu.

Simptomnya berbeza dalam setiap tanda amaran. Struktur asasnya adalah sama: dua fungsi yang berdekatan secara organisasi tetapi terputus dari segi maklumat.

Penyelesaiannya bukan alat baru. Bukan bengkel budaya. Ia adalah perjanjian penghalaan maklum balas, cukup spesifik sehingga kedua-dua pihak tahu tepat apa yang mereka miliki, bagaimana ia mengalir, dan bila gelung ditutup, dipegang secara konsisten cukup lama untuk menjadi cara sesuatu berfungsi dan bukannya projek yang berjalan selama dua suku tahun dan kemudian berhenti secara senyap.

Analisis Rework: Lapan tanda amaran berkelompok kepada dua punca akar apabila anda menjalankan diagnostik merentasi pasukan. Tanda 1, 3, 4, dan 8 terutamanya berpunca daripada penghalaan maklum balas yang hilang: isyarat CS wujud tetapi tidak sampai kepada keputusan produk dalam bentuk yang mengubahnya. Tanda 2, 5, 6, dan 7 terutamanya berpunca daripada komunikasi pelan hala tuju yang hilang: keputusan produk tidak mengalir kembali ke CS pada masa atau bentuk yang boleh digunakan. Kedua-dua arah jurang maklumat CS-Produk diwakili. Organisasi yang menganggap masalah itu satu sisi (hanya membaiki penghalaan VoC, atau hanya meningkatkan komunikasi pelan hala tuju) biasanya menyelesaikan 4 daripada 8 tanda amaran dan tertanya-tanya mengapa 4 yang lain berterusan. Penyelesaiannya memerlukan penutupan kedua-dua arah jurang maklumat secara serentak. Modul penjajaran CS-Produk Rework menyerlahkan kedua-dua arah: penghalaan maklum balas masuk (tangkap, tag, wajaran, halakan) dan komunikasi pelan hala tuju keluar (taklimat pra-pengumuman, pemberitahuan gelung tertutup, penyelarasan beta).

Apa yang Perlu Dilakukan Seterusnya

Jika anda mengenali tiga atau lebih tanda-tanda ini dalam organisasi anda, artikel kos ketidakselarasan CS-Produk membimbing cara mengukur apa yang ia kos anda dalam istilah yang relevan dalam perbualan CFO atau CRO. Model kematangan adalah diagnostik yang lebih lengkap. Ia menempatkan anda pada peringkat tertentu dan mengenal pasti dua atau tiga langkah yang mengalihkan anda ke peringkat seterusnya.

Jika anda mengenali enam atau lebih, jangan mulakan dengan penilaian model kematangan. Mulailah dengan penilaian kendiri dalam artikel model kematangan, bawa skor itu ke sinkronisasi CS-Produk seterusnya, dan bersetuju dengan satu perubahan yang akan anda pegang selama 90 hari berikutnya sebelum menambah apa-apa lagi. Penjajaran bertambah baik paling cepat apabila organisasi boleh menunjuk kepada satu perubahan konkrit yang benar-benar berfungsi, bukan apabila ia menjalankan enam penambahbaikan proses serentak yang tiada seorang pun memilikinya dengan jelas.

Soalan Lazim

Berapa banyak tanda amaran yang menunjukkan masalah penjajaran yang serius?

Melihat satu atau dua tanda amaran biasanya menunjukkan jurang operasi tertentu yang boleh diperbaiki dengan intervensi yang disasarkan. Melihat lima atau enam mencadangkan model operasi antara CS dan Produk pada asasnya rosak dan bukannya sebahagian sahaja yang merosot. Pada ketika itu, penyelesaiannya bukan pembetulan satu isu; ia adalah pendekatan berstruktur untuk membina semula gelung maklum balas dari awal, biasanya bermula dengan peralihan Peringkat 1 kepada 2 dalam model kematangan.

Apakah tanda amaran yang paling cepat diperbaiki?

Tanda Amaran 2 (CSM tidak dapat menjawab "bila X akan datang?") biasanya yang paling cepat ditangani. Ia memerlukan satu perjanjian operasi (tetingkap pra-pengumuman dua minggu) dan menghasilkan peningkatan ketara segera dalam keyakinan CSM. Tanda Amaran 1 (aduan yang sama selama dua suku tahun) mengambil masa lebih lama kerana ia memerlukan pembinaan infrastruktur pengagregatan dan pembentangan corak kepada Produk dalam format yang mengubah keputusan pengutamaan.

Tanda amaran mana yang paling mahal untuk diabaikan?

Tanda Amaran 8 (NRR mendatar dengan kelajuan penghantaran ciri tinggi) adalah yang paling mahal kerana ia bertambah buruk dari masa ke masa tanpa isyarat krisis yang jelas. Kelajuan penghantaran ciri kelihatan seperti kemajuan. NRR mendatar kelihatan seperti masalah pasaran. Hubungan antara keduanya hanya kelihatan dalam retrospek: ciri-ciri tidak menggerakkan penanda pengekalan kerana ia tidak berasas pada isyarat yang bersumber CS. Menjelang corak itu jelas, beberapa suku tahun pelaburan kejuruteraan telah menuju kepada hipotesis dan bukannya masalah yang berkaitan dengan pengekalan.

Bagaimana anda membawa perbualan tanda amaran kepada Head of Product tanpa ia terasa seperti tuduhan?

Rangkakan ia sebagai penilaian kendiri dan bukannya kritikan. "Mari kita semak diri kita terhadap senarai ini bersama-sama" adalah berbeza daripada "inilah yang Product lakukan dengan salah." Tanda amaran direka untuk mengimplikasikan kedua-dua pihak. Kepimpinan CS akan mengenali kegagalan penghalaan maklum balas di pihak mereka sendiri (tanda 1, 5, 6) bersama kegagalan komunikasi pelan hala tuju yang biasanya berpunca dari Produk (tanda 2, 4). Bacaan seimbang kesemua lapan biasanya menghasilkan perbualan tentang reka bentuk sistem bersama dan bukannya salah individu.

Adakah diagnostik ini perlu dijalankan setiap tahun?

Tanda amaran paling berguna sebagai diagnostik titik permulaan untuk pasukan yang belum pernah menilai penjajarannya sebelum ini, atau selepas perubahan pasukan yang signifikan (VP CS baru, Head of Product baru, penstrukturan semula organisasi yang besar). Untuk penjejakan berterusan, penilaian kendiri model kematangan lebih berguna kerana ia memberikan skor yang berubah dari masa ke masa. Jalankan setiap suku tahun untuk tahun pertama kerja penjajaran aktif; setiap tahun setelah model operasi Peringkat 3 stabil.

Apakah hubungan antara Tanda Amaran 8 (NRR mendatar + kelajuan tinggi) dan tanda amaran lain?

Tanda Amaran 8 biasanya adalah hasil lewat tanda 1-7. Jika CSM menangani aduan yang sama selama lebih daripada dua suku tahun (Tanda 1), jika CS tidak dapat menjawab soalan pelan hala tuju (Tanda 2), jika ciri mendarat tanpa sokongan penggunaan CS (Tanda 3), dan jika backlog penuh dengan permintaan lapuk (Tanda 4), hasil kumulatifnya adalah produk yang menghantar secara berterusan tetapi tidak menggerakkan penanda pengekalan. Tanda 8 adalah hasil kewangan; tanda 1-7 adalah sebab operasi. Mengenal pasti tanda hulu mana yang aktif memberitahu anda di mana pembaikan perlu dimulakan.

Bagaimana anda membezakan masalah kadar peralihan pelanggan kerana kualiti produk daripada masalah kadar peralihan kerana ketidakselarasan?

Periksa sama ada jurang produk yang memacu kadar peralihan pelanggan diketahui oleh CS sebelum akaun meninggalkan syarikat. Tarik kod temu bual keluar dan padankan dengan nota CSM dari dua kitaran QBR terakhir. Jika jurang yang sama muncul dalam kedua-duanya (CSM menandakannya, pelanggan menyebutnya semasa keluar) kadar peralihan itu disebabkan ketidakselarasan: isyarat wujud tetapi tidak dihalakan kepada keputusan. Jika jurang muncul semasa keluar tanpa sebarang isyarat CS sebelumnya, masalahnya adalah kualiti produk, bukan penjajaran. Kebanyakan organisasi mendapati campuran: kira-kira 50-70% kadar peralihan jurang produk menunjukkan isyarat CS sebelumnya, berdasarkan data penanda aras Gainsight.

Bolehkah tanda amaran muncul secara berasingan, atau adakah ia sentiasa berkelompok?

Ia hampir sentiasa berkelompok. Tanda 1 (aduan berulang) dan Tanda 4 (backlog lapuk) muncul bersama kerana kedua-duanya adalah simptom gelung maklum balas yang rosak. Tanda 2 (CSM tidak dapat menjawab soalan pelan hala tuju) dan Tanda 3 (penggunaan ciri rendah) muncul bersama kerana kedua-duanya berpunca dari komunikasi pelan hala tuju yang tiba terlambat. Tanda 5 (maklum balas pelanggan yang tidak boleh dikesan sumbernya) dan Tanda 6 (definisi keutamaan yang berbeza) muncul bersama kerana kedua-duanya berpunca dari ketiadaan rekod maklum balas yang dikongsi. Melihat satu tanda terpencil biasanya bermakna tanda lain dalam kelompoknya wujud tetapi belum kelihatan.

Ketahui Lebih Lanjut

Tara Minh

Senior Operations & Growth Strategist