登壇者
高山 晋【プレイド / カスタマーサクセス】

プレイドについて

プロダクトでサクセスを実現する

前提・どの様な思い出プロダクトに携わり、プロダクトを作っているのか。
カスタマーサクセスはロールではなく、企業全員で取り組むべき。

チーム編成
Biz × Dev がうまく噛み合わないと、プロダクトのポテンシャルが発揮できない可能性が高くなる。

WhyとHow
Why：なぜやるのか、MissionやValue
How：どの様にやるのか、全員が自走できる構造
これから外れた行為は個人の満足度の向上にしか繋がらない。

Mission：データによって人の価値を最大化する
サイト来訪者が何を考えているかがわからない＝データが整理出来ていない状態。それを直感的にわかるような形に整理してあげる、世の中に顕在化していない価値を提供する。

Mission実現のための行動様式
Backcasting・Deploy Driven・Unlearning

プロダクト × 人

人ドリブン
国内のBtoBサービスは人に頼ったものが多い。純粋にSaaSだけで事業を推進しているものは少ない印象。
→労働集約的で、プロダクトが成長しづらく、ビジネスとしてスケールしにくい。
プロダクトドリブン
プロダクトが高度になればなるほど、セルフサーブで使って貰いにくくなる。プロダクトをサポートするプロフェッショナルの取り合いになりがち。

プレイド＝プロダクトカンパニー
ただし、ナレッジを貯めるためにあえて「人」を介在させて行くことが今は必要だと考えている。出来る領域が広いため、学び＝プロダクトの為になる取り組み、を重視している。極論売上よりも重視。

プロダクトでの解決 × 人による解決

プロダクトで解決
データとナレッジを規格化。
例えば、、
ナレッジストア：あらゆるナレッジをデータベース化し簡単に利用できる
カルテデータハブ・クエリコレクション：SQLを書かなくてもデータ抽出が可能

人で解決
好循環のフィードバックループを回していく

セルフサーブではない部分を見つけ、解決していく

様々な接点からリクエストをもらえる設計に
例えば、、
チャットサポート：全クライアントに無償で提供。クライアントの要望を収集
NPS：定期的にクライアントのNPSを取得
Forum：顧客同士のコミュニケーションから要望を収集

プロダクトドリブンでフィードバック対応
すぐに回答を出すのではなく、一旦エンジニアにエスカレし、全クライアントに価値提供出来る形が無いか検討してから回答。

難しいポイント
組織のスケールに伴う問題に立ち向かう。人が増えることで、組織上の課題が発生。

まとめ