カスタマーサポート領域のコンパウンドスタートアップで挑戦するプロダクトマネジメント
こんにちは。株式会社RightTouchで主にプロダクトマネージャー（以下PdM）をやっている武藤です。
【簡単な自己紹介】
慶應義塾大学経済学部卒業後、2014年に新卒でリクルートホールディングスに入社。入社後は大規模サービスのグロース、エンジニアリング、新規プロダクトの立ち上げなどに一貫してプロダクト開発に従事。2019年にプレイドに参画後は主に0→1、1→10フェーズでの事業推進をロールを問わず担当。現在はRightTouchにて、複数プロダクトのプロダクトマネジメント及び事業推進をリード。お笑いと音楽とバスケが好き。
本エントリーでは、ざっくりコンパウンドスタートアップにおけるプロダクトマネジメントについて書きたいと思います。
コンパウンドスタートアップの概念や考え方に関するエントリーは直近増えてきつつも、具体的にどう取り組んでいるのか？まで含めて説明されている記事はまだ少ないなと思って今回筆を取りました。
このnoteでは、コンパウンドスタートアップの概念はざっくりご存知の前提で、コンパウンドスタートアップにおける具体的な事業・プロダクト運営に興味を持っているPdMや事業責任者ロールの方向けに書いてみます。
そもそもコンパウンドスタートアップとは？については以下の記事がよくまとまっていると思うので読んでみてください。
コンパウンドスタートアップのplaybook
コンパウンドスタートアップの概念の提唱者であるRipplingのplaybookによると、以下の3点が重要なポイントとして挙げられています。
1. Integration is the product（＝連携そのものがプロダクト）
2. Maximize the price of your bundle - but undercut the price of each SKU（＝バンドル価格の最大化）
3. When structuring your startup, aim for “parallel execution”（＝並行して実行せよ）
本エントリーでは、この3つのポイントに沿って話せればと思います。
KARTE Talkとは？
本題に入る前に、自分が現在PdMとして担当しているプロダクトの1つであるKARTE Talk（以下、Talk）について簡単に紹介させてください。所謂ウェブチャットのプロダクトで、Webサイト上で顧客と企業間での1to1コミュニケーションが行えます。問い合わせ前にどんなページ（商品ページ・FAQページ等）を見たのか、サイト上でどんなエラーが発生したのかなどの行動データや、会員・非会員といった顧客の属性データを活用して
1. パーソナライズされた問い合わせ導線によるノンボイス比率（※）の向上
2. オペレーターへのデータ還元による顧客対応品質や生産性向上
が行える点が主な特徴になります。
※電話以外のチャネルで解決できた問い合わせの比率
一言でウェブチャットと言っても、エンタープライズ向けなのかスモールビジネス向けなのか、カスタマーサポート領域なのかセールス&マーケティング領域なのか等、会社によってポジショニングやGo To Market戦略はもちろん異なると思います。RightTouchの事業の現在地としてはエンタープライズ×カスタマーサポートというドメインにポジションニングして、プロダクト開発を行っています。
本エントリーでは具体的に言及しませんが、ここにポジショニングしている背景は主に以下の3つになります。
[マーケット観点] 市場規模/予算規模・負も大きい、かつカスタマーサポートの業界全体のトレンドとしてノンボイス化の流れが来ている
[競合環境観点] 電話と比べて有人チャットはまだ発展途上なので、エンタープライズマーケットでの主要プレイヤーは限定的
[自社観点] RightTouchの現状持っているアセット（問い合わせ前データ）と組み合わせることで提供価値をより最大化できる余地がある
‘Integration is the product’
前置きが長くなりましたが、playbook1つ目の「Intergraion is the product＝連携そのものがプロダクト」について自分なりの考えを書きたいと思います。
連携そのものがプロダクトというのは、一般的に以下の2つの価値によるものだと考えています。
共通管理画面による管理、運用の一元化
・別システムを跨いでログインして活用する必要がない
・システムごとに異なる仕様を都度インプットする必要がないプロダクト間のインテグレーションコストが不要
・プロダクト間の連携には通常連携のための開発が必要になるが、基盤が同じであればワンストップですぐに活用できる
冒頭シェアした神前さんのnoteにもありましたが、SaaSの普及によるシステムのアンバンドル化の揺り戻しで、「データ統合 / データ連携」は日常の業務オペレーションを行っていく上でもはや切っても切り離せない時代になっていると思います。
こういった時代背景において、上記2点を担保できている時点でもすでにプロダクト価値は一定水準を満たせているとは思いますが、個人的にはコンパウンドスタートアップのプロダクト開発においてこの2点だけでは不十分だと考えています。
上記2点に加えて「連携によって生まれる新たな差別化価値を考えることが重要」で、ここを考え抜くことがPdMとしての腕の見せ所だと思っています。
連携による新たな価値というのは、プロダクトA、プロダクトBがあったときにプロダクトA+プロダクトBの足し算ではなく、プロダクトA×プロダクトBの掛け算で生まれる価値のことです。
この辺りはリクルート時代の後輩の加藤くんの記事でかなりわかりやすくまとめられているので、合わせて読んでもらえると良いかと思います。
RightTouchが提供しているWebサポートプラットフォーム「RightSupport by KARTE（以下RightSupport）」とTalk（ウェブチャット）を連携するとどういう価値が生まれるのか、具体例を説明します。
RightSupportは顧客のWeb行動を解析し、困りごとにあった情報を出し分けることができるプロダクトです。FAQサイト構築やコンテンツ管理もできます。
顧客のサポートジャーニーを問い合わせ前〜問い合わせ中〜問い合わせ後と定義していて、両プロダクトのデータとUXをシームレスに連携することによって各プロセスで独自価値を提供しています。
問い合わせ前
やっていること：顧客の問い合わせ内容に応じて、FAQや有人チャット窓口等のサポートチャネルとアサインされるオペレーターチームを最適化（ライトチャネリング※）
※顧客の課題に合わせたサポートチャネル最適化のこと
・火災保険の商品について→商品知識のスキルを持った火災保険対応チームに自動アサイン
価値：顧客の困りごとに合わせてサポートチャネルを最適化することで、ノンボイス比率の向上、及びオペレーター生産性向上に寄与
問い合わせ中
やっていること：
・RightSupportで取得する問い合わせ前データ（閲覧FAQ・困りごと・発生エラー・顧客セグメント）をオペレーターに連携し、チャット画面上で可視化
・オペレーターがチャット画面上でFAQコンテンツを検索、送信
・応対時に気づいた課題点に関してチャット画面上でFAQにコメントを残しておくことで、オペレータ起点でのFAQの修正が可能に価値：オペレーターのチャットラリー数を短縮。対応品質と生産性向上の両面を実現
問い合わせ後
やっていること：RightSupportで取得するWeb行動データとTalkが有する問い合わせデータが顧客軸でワンストップで紐づくことにより、いつ・どこで・誰がつまずいたかを直感的に理解することができ、本質的な課題改善に繋げることができる
例えば…
1. 関連FAQを見てるのに問い合わせ発生
- FAQの情報設計が悪く、役割を果たしていないのでは？（仮説）
- 問い合わせ内容を元に改善箇所を捉えてFAQ内容のアップデートを行う
2. 関連FAQを通らずに問い合わせ発生
- 適切な導線に配置できていなく、顧客が気づきずらいのでは？（仮説）
- 該当導線で関連FAQに気付きやすくなるようサイト導線設計を見直す
価値：サイト導線やページ、FAQコンテンツ改善による自己解決促進と不要な問い合わせの削減
これらの連携がどのように活きているのか？
上記ではRightSupportとTalkの連携例についてご紹介しました。この例からもわかる通り、プロダクト単体での価値向上よりも複数プロダクトの連携による価値向上にフォーカスした活動をビジネス側・開発側共にしています。（※あくまでも現時点において。他のプロダクト、事業フェーズによって刻々と変化するものだと思います。）
これは次のセクションの話にも通じますが、プロダクト単体での提供ではなく複数プロダクトをバンドルで提供することによる以下の3点が事業的な狙いになるからです。
獲得数・獲得効率の最大化
ARPA最大化
オペレーション業務への進出による継続率向上
“Maximize the price of your bundle - but undercut the price of each SKU”
続いてplaybook2つ目の「Maximize the price of your bundle - but undercut the price of each SKU（＝バンドル価格の最大化、SKU単位では安くする）」についてです。
異なるマーケット・ターゲットに対して、全く異なるプロダクト群を開発・提供している場合、基本的にはプロダクトごとにビジネス側の体制・リソースが必要になります。コンパウンドスタートアップでは、基本的に同一マーケット・ターゲットに対して複数のプロダクト群を提供することが前提になってくるので、うまくいけば顧客獲得コストが削減されビジネスリソースを効率化できます。
とにかくリソースが制約されているスタートアップにおいてはメリットがありますが、その分複数プロダクトを顧客のニーズに合わせて提案していく必要があるため、コンパウンドにプロダクトがどんどん増えていくに従ってビジネス側（Sales/Success）の難易度は高くなります。
RightTouchでも日々試行錯誤しており現時点での正解はないですが、機会として初回商談から全体のケーパリティを提示した上での複数プロダクト/機能でのバンドル提案や、単一プロダクトを利用している既存顧客へのX-Sellのケースも増えてきています。
また、同一マーケット、ターゲットに対して提供できるということはその分マージンコントロールも効かせやすいというのも特徴です。例えば以下のようなイメージです。
将来的なプロダクトB+Cのバンドル提供を見据えた上で、初期の導入ハードルを下げるために安価なプロダクトAのみ提供する（エントリーポイントとして）
粘着性を高めるためによりオペレーショナルなプロダクトA+プロダクトBを一定の割引率でセットで提供する（スイッチングコストを上げるため）
これらを考える際に重要なのが「プロダクト単体ではなく、事業、会社全体を俯瞰した上で位置付けを意識する」ことです。
コンパウンドでプロダクトを複数立ち上げていく目的は、端的にいえばNRRの最大化だと思っています。そこにおいて、各プロダクトが
そのプロダクトを提供する目的・意義は何なのか？
3つの変数（獲得数/獲得効率、ARPA、継続率）のどこにヒットするものなのか？
それらを踏まえ、今どこにフォーカスすべきなのか？
などを言語化しておくことが大事だと思っています。Talkを例に挙げるとざっくりですが以下になります。
プロダクトとしてのstickiness（粘着性）向上
・Talkのような実際のオペレーションを担うプロダクトは、一度価値が実感されると顧客が他の代替品に切り替えることが難しくなる特性（スイッチングコストが高い）がある問い合わせ前のWeb行動データに加えて、実際の問い合わせデータを抑え繋げることによる独自価値の提供
・上述した問い合わせデータ連携の話が一例
1（オペレーションへの浸透によるstickiness向上）と2（独自価値による代替手段がない状態）によって顧客にとってMust Haveな状態を作ることができ、それにより会社全体の事業成長に寄与できる、という整理をしています。
2の独自価値に関してもう一つ事例を紹介します。オペレーター支援というユースケースと生成AIは親和性が高いので、Talkにおいても生成AIを絡めた価値創出は引き続き積極的に進めていきたいと思っています。
ただ、当然各社も開発を推し進めていく分野であり比較的コモディティ化しやすいため、1点目のパートでも記載した「連携によって生まれる新たな差別化価値を考えることが重要」というのがここでも大事になってきます。単なるトレンドに合わせるのではなく、自分達の有するアセットとうまくシナジーを作れるような機能開発を今後も考えていきます。
Talkに限らず、RightTouchの生成AIに関するスタンスについてはテックリードの齋藤の記事に詳しく書いてあるのでこちらも合わせてご確認ください。
全社戦略とプロダクト戦略のアライン / 全体バランスを鑑みた開発優先度
全社戦略とプロダクト戦略のアラインに関しては代表の長崎・取締役の藪と定期的にコミュニケーションを取りながら、プロダクトごとに半年〜1年くらいの開発ロードマップを作成しています。個別案件については開発メンバーと議論しながらブレイクダウン→要件に落とし込んでいます。
また、もちろんプロダクト価値向上のための「攻め」の開発だけではなく、以下のような「守り」の開発も併せて行っていく必要があります。
管理画面内のパフォーマンスチューニング系
・オペレーション領域のプロダクトなので、管理画面内のパフォーマンス低下そのものが非利用理由になり得る競合サービスと比較した際に、そもそも機能がないことがノックアウトファクターになる系
安定稼働のためのインフラ整備、コードリファクタリング系
TalkはRightSupportと比較すると比較的歴史が長めのプロダクトになるので、
依存するプロダクトが多岐に渡る・関連するシステムも多い
顧客側・オペレーター側で複数のバージョンがあってメンテナンスするカバー範囲が広い
という特徴があるのに加え、日常オペレーション領域のプロダクトになるため、一般的なSaaSプロダクトよりも高いサービスレベルが要求されるという実情もあります。この辺りの全体のバランス感は常に意識しながら開発を進めています。
Organize the company to parallelize execution
こちらについてはどちらかというと組織設計の要素が強い箇所なので、今回は割愛します。コンパウンドスタートアップにおける最適な組織設計については日々試行錯誤しながら模索をしている最中なので、また活動するなかで知見が溜まってきたら追って公開したいと思っています。
まとめ
今回のエントリーでは、コンパウンドスタートアップにおけるプロダクトマネジメントの具体について、Talkの実例をベースに紹介しました。自分たちもコンパウンドスタートアップとして日々手探りで進めている状態で、大小含め課題も様々ありますが、優秀なメンバーとともに複数事業・プロダクトを立ち上げていくプロセスはシンプルに楽しいです。
自分の好きな言葉に「人数は線形に、事業は非線形に」という言葉があります。一人ひとりが事業・プロダクトにオーナーシップを持ちながら、小さいチームで大きなインパクトを出していきたいと思います。
一緒に働く仲間を募集しています
上記と矛盾するように見えますが（笑）、コンパウンドにこれからも新しい事業・プロダクトを立ち上げていく上で、ビジネス・プロダクトともに全然人が足りていません。このnoteでRightTouchに少しでも興味をくれた方、ざっくばらんな雑談やカジュアル面談からでも大歓迎ですので以下リンクからご応募お待ちしています！
この記事が気に入ったらサポートをしてみませんか？