← エピソード一覧に戻る Episode 240 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 顧客の声を集めても、なぜ解約は減らないのか
タカシ
皆さんこんにちは、タカシです。今日は SaaS CS の VOCループを扱います。顧客の声は毎日たくさん入るのに、解約も要望の取りこぼしも減らない会社があります。原因は、声を集めているのに循環させていないからです。
ミカ
ミカです。ありますね。CS がすごく丁寧にヒアリングしているのに、product には届かない、届いても顧客へ戻らない、みたいな状態。聞いているのに、なぜか誰も前進した感じがしないんですよね。
タカシ
VOCループは、顧客の声を集めることではなく、収集して、構造化して、優先順位をつけて、改善し、結果を顧客へ返し、さらに活用まで確認する流れです。SaaS ではこの輪が閉じてはじめて churn prevention が機能します。
ミカ
今日は、CS が product の伝書鳩で終わらないための設計ですね。どんな会社がうまく回しているのか、あと声の大きい顧客に引っ張られない見方も聞きたいです。
Chapter 2 基本 ― VOCループは収集よりも文脈の接続が本体
タカシ
まず大事なのは、ticket、QBR、営業商談、コミュニティ、NPS、解約理由など、入口が違っても同じ土台に載せることです。CS が会議メモだけで共有すると、顧客の原文、痛みの強さ、契約規模、更新時期が抜け落ちやすいんですね。
ミカ
要するに、要約しすぎると危ないわけですね。『CSV が欲しい』だけ残っても、監査対応なのか役員報告なのか、あるいは今月更新だから焦っているのかで、重みが全然変わりますもんね。
タカシ
その通りです。Linear は CX が Intercom や Slack から声を issue 化するとき、顧客の正確な言葉と元会話へのリンクを残しています。つまり、product や engineering が後から読んでも、なぜ困っているかの温度が落ちにくい設計なんです。
ミカ
ここ、すごく大事ですね。CS だけが文脈を知っている状態だと、担当者が変わった瞬間に loop が切れます。原文と顧客情報が残っていれば、部署をまたいでも同じ痛みを見ながら判断できます。
タカシ
さらに優先順位は件数だけで決めません。Linear は candidate project を関連 request 数と revenue impact で並べますし、CS 側は renewal risk や tier を重ねて見るべきです。VOCループは一票の多数決ではなく、経営文脈つきの意思決定なんですね。
Chapter 3 実務例 ― うまい会社は戻し方まで設計している
タカシ
Linear の面白いところは、issue が Done になると Intercom 側の会話が自動で reopen され、CX が顧客へ update しやすくなる点です。つまり『直した』で終わらず、『直ったので確認してください』まで workflow に入っているんです。
ミカ
それは気持ちいいですね。顧客からすると、言ったけど消えた、が一番つらい。直った瞬間に会話へ戻れるなら、ちゃんと聞かれていた感覚が残るし、次の feedback も出しやすくなりそうです。
タカシ
Productboard の GSoft も典型例です。導入 1 年で customer feedback contributed は 2倍、maker は週 2 時間ずつ節約できました。しかも MVP テストで約 50 件の反応から契約社員の除外ニーズを見つけ、1 カ月以内に同じ顧客群へ修正版を返しています。
ミカ
件数が増えたことより、戻す速度が速いのが効いていますね。『言ったら数週間で変わった』を一度でも体験すると、顧客はこの会社は本当に listening していると感じる。trust の作り方としてかなり強いです。
タカシ
Appcues の事例も良いです。sales や CX からの request を Canny に集め、votes や comments を Salesforce に流し込み、MRR で並べ替えて顧客更新に使っています。要望を backlog に積むだけでなく、beta tester 発掘にも使っているんですね。
Chapter 4 深掘り ― リリースで終わらず adoption と churn recovery を見る
タカシ
VOCループが難しいのは、リリース通知を送るだけでは閉じたことにならない点です。Sonar Software は以前、800 件超の feedback が散らばり、小さな team では整理だけで消耗していました。統合後は、誰が要望したかと、リリース後に使っているかまで追えるようになりました。
ミカ
そこが SaaS っぽいですね。機能を出しました、ではなく、その顧客が本当に使って価値を感じたかまで見ないと、更新率にも NRR にもつながらない。特に解約予備軍には、出荷後の伴走が要りそうです。
タカシ
その通りです。たとえば高リスクアカウントが欲しがっていた改善を出したなら、30 日後に activation、重要機能の利用、問い合わせ減少、更新交渉の温度まで見たい。ここまで見て初めて、VOC が churn recovery に効いたか学習できます。
ミカ
逆に言うと、『作ったのに解約した』ケースも宝ですね。作る内容がずれていたのか、知らせ方が悪かったのか、オンボーディングや enablement の問題なのかが見える。release note だけ読まれて終わると、そこが全部分からなくなります。
タカシ
Atlassian が 2025 年に support と product、dev、ops を単一基盤へ寄せ、年換算最大 1000 万ドルの support cost 削減と CSAT 6% 向上を見込むと公表したのも同じ話です。分断を減らすほど、返答速度と学習速度が一緒に上がるんです。
Chapter 5 クロージング ― 明日から始める VOCループの作り方
タカシ
実務ではまず、VOC intake の必須項目を決めてください。チャネル、顧客名、セグメント、ARR、renewal timing、困っている業務、そして原文です。これがないと、あとで優先順位も顧客返答も曖昧になります。
ミカ
そのうえで weekly に三つ見るんですね。未処理 feedback、顧客へ返答待ちの案件、そしてリリース済みだけどまだ使われていない案件。この三つを並べるだけで、集めっぱなし病はかなり防げそうです。
タカシ
ええ。VOCループは customer centric をきれいに語る仕組みではなく、継続率と trust を作る運営システムです。聞いて終わらず、返して終わらず、使われるまで追う。この一歩を踏み込める CS が、SaaS の成長速度を変えます。今日は VOCループを取り上げました。ではまた次回。