「貴重なご意見ありがとうございます」で終わらせないCS——マネージャーの"質問"が、プロダクトの要件になるまで
こんにちは。KUDEN WORLDでカスタマーサクセスを担当している山本です。
肩書きは「CS＆コミュニケーション」と聞き馴染みはないと思いますが現場と並行して、発信もしています。
KUDENのnoteはこれまで、2つのテーマーー
①「なぜ組織進化OSを作るのか」という思想
②「それをどんな構造で実現するのか」という設計
で発信してきました。
この記事は、その2つと異なる、いわば「実録モノ」。
思想と構造、その間を埋める連載です。
思想は主張で、構造は設計図。どちらも思い描くだけ、言うだけなら、簡単にできます。ですが、現場で実際に起きたことだけは、そこにしかありません。
「全ては人から」というコーチングを核としたスタートアップが、いまいかにして事業をアップデートし社会実装しようとしているのか。
その現在進行形の様子をお伝えしつつ、ログとして残したいと思います。
不定期ですが、現場が動いている限り続きます。
今回のテーマは、AIプロダクト「KUDEN Biz」をご利用いただいている企業との対話、マネージャーの"なにげないひと言"がプロダクトの要件文書（PRD）になった話です。
KUDENのカスタマーサクセスの業務内容を、端的に表しているエピソードだと思うので、最初に書くことにしました。
ある質問から始まった
きっかけは、導入いただいている企業様との定例ミーティングに同席していたときのこと。マネージャーのお一人が、こう質問されました。
「部下のレポートへのコメントをどう書けばいいかも、MYコーチに聞けばいいの？」
機能のご案内を一通り終え、使い方について追加質問のひとつ。
なにげない一言でした。
私たちが提供しているKUDEN Bizの中には、「AIリフレクション」というメンバーが日々の振り返り（デイリーチェックイン）をAIコーチと行う機能と、すべてのレポート情報を組織知として蓄積し個別に対話できる「MYコーチ」機能があります。
振り返りはレポートとして上司へ日次で届き、上司はそのレポートについて、コメントを返せる。
その一連の流れをイメージされて、発せられた、ひと言。
その場では担当がお答えし、ミーティングは次の議題へ進みました。
ここまでは、どのサービスのカスタマーサクセスでも同じだと思います。
違いが出るのは、ここからです。
「声」は、そのままでは要件にならない
このように複数寄せられる内容については、「よくあるご質問」に追加して完了することもできます。実際、その選択をするプロダクトは少なくないはずです。
しかし、私たちはこの質問をこう翻訳しました。
「部下に反応を返したい。しかし、コメントの返信にもマネージャーは慎重であり、迷いもするしより良い回答を、AIへ相談したいケースもある」
ユーザーは、「もっとこうして欲しい」というリクエストを必ずしも直球で投げてくれるわけではありません。
自身の主業務を行う中で、利用中の１サービスに対して、大きな障壁ではなく、一瞬の「あれ？」と感じた違和感を言語化、かつ伝えるにもカロリーが必要です。
そんな中で、使い方の質問という形で、本音がぽろっと漏れる。
違和感の小石を取り除きノンストレスに使えること、意識さえしないスムーズさは、実はこの積み重ねの賜物です。
発展途上のプロダクトを磨き続けるチームだからこそ、不具合でもリクエストでもないひと言が、改善のタネに一瞬で変わることに、敏感でいたいと改めて感じた出来事でした。
コーチングを長年生業にしてきた私たちのカルチャーには、「コーチャブルであること」というマインドがあります。
まず受け止めて、試みる姿勢。
ただ、「聞かれたことに答える」ことと「質問の奥にある課題の"なぜ"を特定する」ことは、似ているようでまったく別の仕事です。
カスタマーサクセスは、プロダクトとユーザーの触媒——翻訳者になることで、顧客の声を蒸発させることなく開発チームへ届けます。
声に濃淡があっても、キャッチの仕方で届き方は変わります。
ひとつの質問が、3つの要件になった
翻訳した課題を起点に、開発チームと一緒に「コメントを返す側の体験」を遡っていくと、それはそれは芋づる式に課題が繋がっていきました。
コメントを書いても、相手に通知が届かない
（届けたかった承認のひと言が、相手に届いたかを確認できない）マネージャーは、どのレポートを読み終えたかが一覧で分からない
（確認漏れと二度読み発生の可能性）「読んだよ」と軽く伝える手段がない
（時間をかけてコメントを書くか、無反応か、の二択）
ひとつひとつは小さな欠落です。でも束ねると、こういうことになります。
「コメント機能」はあった。でも「コメントが続く構造」が、なかった。
マネージャーがコメントに悩みAIと壁打ちしたいと感じるのは、機能の使い方ではなく、フィードバックを返す行為そのものが、仕組みに支えられていなかったから。
あの質問は、その構造の欠落が漏れ出た瞬間でした。
この課題群は、それぞれ要件文書（PRD）として起票され、次スプリント（開発の周期）で開発タスクに載りました。
新着コメントの通知、既読未読の表示、コメントリアクションボタンの設置がなされ、あの日の会話を起点に、段階的に画面へ反映されていきました。
その後の話を、少しだけ。
現在では、メンバーの振り返りレポート提出を起点に、マネージャーからのコメントやサムアップ!スタンプがつくようになり、コミュニケーションの始まりを目の当たりにしています👍
（次の仕事は、この動きをどう「続くもの」にするかです）
重要なのは、カスタマーサクセスが「コメント機能を使いやすくしてください」と依頼したのではない、ということです。
機能改善の依頼として渡していたら、直ったのはどれかひとつだけだったでしょう。
「マネージャーの"真摯に回答したい"という意欲が、仕組みの重さに負けている」という課題として渡したことがトリガーとなり、開発チームはコミュニケーションの設計ごと見直すことになった。
限られた時間でスプリントを回す開発チームに、どの解像度で声を渡すか——そこまでがカスタマーサクセスの仕事だと考えています。
声はひとつ。要件は3つ。
カスタマーボイスの翻訳の質が、プロダクトを磨き、ひいては「また使いたい」というUXを形づくります。
なぜ、すぐに動き出せるのか
「小さい会社だから速いんでしょ」と言われたら、それは半分正解です。
KUDENのチームにおいて、カスタマーサクセスと開発チームの距離はとても近い。
でも、それだけなら「サイズ感だけの速さ」で終わります。
もう半分の理由は、声の通り道が設計されていることです。
KUDENでは、顧客の声やテストでの気づきが、事業要求→プロダクト要件→仕様、という決まった形式の文書に翻訳されて開発に届く動線を運用しています。
カスタマーサクセスが拾った一言には、置き場所と、要件になるまでの経路が最初から用意されている。 人数が少ないから速いのではなく、通り道があるから、少人数でも声が消えない。
この動線の仕組み化も最初から完成していたわけではありません。試行錯誤の途中であり、この連載自体がその記録になっていく予定です。
少人数のチームがAIを使い倒しながらサイクルを回し続け改良を続けることが、サービス、プロダクトを育てることにつながると感じています。
KUDENのCSは、何の仕事か
カスタマーサクセスには、「対応を閉じること」をゴールにPDCAを回す業務もあります。
その声がプロダクトのどこに反映されたのか、見届ける前に次のチケットが来るケースもあるでしょう。
チケットを閉じる。滞らせることなく次へと進む。
仕組みが構築され、すでに形が整えられている完成形ともいえるサービスにおいては、品質保持やブランディングの視点からも、対応を最適に閉じることが最重要です。
その観点から見ると、KUDENのカスタマーサクセスは、逆張りかもしれません。 対応が終わったところから、仕事が始まる。
このやり方を、私たちは最近「粘着型カスタマーサクセス」と呼びはじめています。
"粘着"——あまり良い意味では使われない言葉なのに、あえて選んだこの言葉。目指していることは何なのか。
気になった方はぜひ、次回の記事も読んでください。
拾う。翻訳する。要件にして届ける。
やがて、ユーザーの画面が変わる。 あの日の"質問"に、機能で答えていく。
その一連の流れを、ひとりのカスタマーサクセスが最初から最後まで見届けることができます。
この距離の近さとダイレクトな動き方が、現時点のKUDENのカスタマーサクセスの働き方です。
まとめ
顧客の声は、そのままでは要件にならない。翻訳するのがカスタマーサクセスの仕事
KUDENには、翻訳された声がPRDになる、開発にすぐに届く「通り道＝パス」がある
ひとつの"質問"が、3つの要件になった。通り道が実在する、なによりの証拠
改めて、カスタマーサクセスというポジションは、掘れば掘るほど仕事が湧き出てきます。
でも、それは循環している証拠でもある。
決まった対応にどこか違和感を持ったCSの方。
プロダクトに声が届かないもどかしさ、悔しさを知っている方。
KUDENのカスタマーサクセスの話を、もう少し聞いてみませんか。
SNSのリプライでもDMでも、お気軽にどうぞ🙋♀️🙋
▼KUDEN WORLD ＜カスタマーサクセス＞採用ページはこちら↓
