見出し画像

とあるカスタマーサクセスの失敗目録【Customer Failure】

やすまさ@パパゲーノ

顧客を成功へ導くCS(Customer Success)がやってしまった、失敗。顧客の失敗（Customer Failure）を繰り返さないよう参考にしていただけたら幸いです。

産業保健×SaaSの特徴

僕は働くひとと組織の健康という「産業保健」の分野で、企業の人事労務や産業医(働くひとの健康管理を専門にする医師)の業務を効率化するクラウドサービス「Carely」のカスタマーサクセス(CS)チームのマネジメントをしていました。産業保健分野のSaaSには以下のような特徴があります。

【産業保健SaaSの特徴】
・法律で義務づけられていることが多いが微妙なルールが会社ごとに異なる。
・医療機関や健康保険組合にて、紙の文化、FAXの文化が根強い。
・健康診断の予約やデータ入力といったアナログ業務に工数をとられすぎていて、本来やるべき働くひとの健康に貢献する仕事に集中できていない
・専門性が高く、産業医、保健師などの専門家が力をもっている。
・働き方改革、健康経営、DXなど、市場全体として追い風である。

こんなSaaSのカスタマーサクセスとして、やってしまった8つの失敗談と学びをまとめます。

スライド42

【失敗1】オンボーディング＝機能説明

初めてCSとして働き出した頃の僕は、ひとまず「青本」を読んで、試行錯誤しながら仕事を覚えていました。当時は、オンボーディングのことを「プロダクトの機能説明」だと勘違いしていました。

スライド34

デモ環境でCarelyの操作方法を徹底的に学習して、全ての機能について、「何ができて、何ができないか」の説明ができる状態にしていました。それが愚かだったと気づいたのは、初めて客先を訪問したときです。

CS：「こういう機能なんです！(ドヤ顔)」
顧客：「あ〜、その機能は使わないっすねー。」

プロダクトの1つの機能の説明を全力でしてみた結果、「あ〜、うちではそれ使えないですね」と一蹴されました。良いプロダクトなはずなのに、つらい。

この経験から、「ただプロダクトの説明をするだけでは、押し売りの営業と変わらない」と気づきました。それはオンボーディングとは呼べません。オンボーディングの本質は、「顧客の課題特定」と「顧客のToDo」の最適化です。相手がどんな目的を達成すべきで、そのために何が一番解決すべき問題で、いつまでに誰が何をすべきなのか。その中のごく一部に「プロダクトの機能説明」が入ってくるイメージです。

また、オンボーディングに慣れていない頃は「8割自分が話す」という一方的な講義スタイルだったのですが、慣れてからは「8割相手が話す」「相手が手を動かす」という相手中心のオンボーディングスタイルに変更していきました。

【失敗からの学び】
・プロダクトの機能説明をしても、ユーザーは使わない。
・オンボーディングの本質は「顧客の課題特定」と「顧客のToDo」を最適な方向に導くこと。
・顧客とのミーティングでは、8割相手に話してもらう。相手中心のオンボーディングスタイル。

【失敗2】ToDoを見て、顧客を見ない

CSとしての仕事をある程度任せてもらえるようになった僕は、少しずつ業務量が増えて忙しくなっていきました。どこかでToDoをこなしてる自分に酔っていたところがあって「今日も遅くまでよくがんばった！えらい！」と仕事したような気になっていたりしました。

初めて担当したクライアントさんから対面での打ち合わせの希望があったので訪問した時に、すごく素朴なんですけど、思ったことがあって。

「◯◯さんって、こんな顔だったんだ」

その後、このお客さんは「解約」となりました。主にはプロダクトの価値とコストが見合わないと判断されての解約でした。初めて担当したお客さんで、それなりに時間もかけて必死に対応していただけに、悔しかったです。今でもそのお客さんの最寄駅を電車で通ると、あの時のなんともいえない感情を思い出します。

スライド36

相手の顔をイメージするだけでも、メールや電話での対応の丁寧さって変わると思うんですね。無味乾燥な作業の処理的な感覚で仕事をしていると、数値化できない顧客の機微を見逃して痛い目を見るなと学びました。

いっぱい作業を処理しても、それは仕事にはなりません。お客さんに価値が届いてはじめて仕事になります。

【失敗からの学び】
・ToDoをこなすことで仕事した気になってはいけない。
・数値化できない顧客の機微に気づけるように、相手の表情をイメージしよう。

【失敗3】プロダクトありきの提案

CSの仕事に慣れてきた僕は、健康診断、ストレスチェック、過重労働管理、衛生委員会、職場巡視、産業医面談といったCarelyの機能が関わる実務の勉強を一生懸命していました。これでもう無敵といえるレベルで知識武装し、ドクターXにハマっていたので、「私、失敗しないので」と心の中で唱えてスイッチONにして、新規の担当企業のオンボーディングに挑んでいました。知識負けすることがまずなくなって、天狗になりかけていた頃に、事件は起こりました。

CS：「◯◯さんが今1番注力していて、工数を使っていることは何ですか？」
顧客：「◯月からの大規模な組織改編に伴う各種制度の見直しや移行管理に1番工数を使っています」

ふぁ！？なんぞそれ。この時の僕の心の中の声を赤裸々に書くとこんな感じです。

「え、”組織改編”ってなにそれ？この人は健康管理業務の担当じゃないの？てっきり、健康診断の準備で忙しいです、とか、ストレスチェックが始めてだからわかりません、とか、そういう回答がくるものと想定してたけど、健康診断の「け」の字もないじゃん。というか、組織改編に伴って◯◯さんは具体的に何に責任を持っていて、どんな業務が発生するんだろう？勉強不足すぎて、全くイメージがつかない…。」

この時の僕は先方の担当者が「健康管理業務をメインにしている人」だと勝手に思い込んでいたんですね。逆にいうと、健康管理業務以外で、管理部門、バックオフィス、コーポレートと呼ばれる部門にどんな業務があるのか、まったくと言っていいほどに無知でした。

プロダクトありき

僕がやってしまった失敗は、「プロダクトに捉われすぎた」ということです。余裕がなくて仕方のない部分もありましたが、プロダクトを中心にヒアリングし、プロダクトを中心に提案をしていました。プロダクトが直接関係しない業務も含めて顧客を理解することの重要性に気づきました。この頃からGoogleアラートで担当企業の名前を必ず登録し、プレスリリースが出たらすぐチェックするようにして、顧客の事業理解にも努めるようになりました。

プロダクトという枠組みに縛られず、フラットに課題をヒアリングして、ゴールを明確化し、そこへ導くための一手段としてプロダクトの使い方を提案する感覚が大切なのかなと思います。

【失敗からの学び】
・顧客の担当者は、プロダクトと関係ない業務でも忙しい。相手の役割や業務範囲の理解を深めることが、円滑なオンボーディングに繋がる。
・プロダクトに縛られずに、フラットな視点で「手ぶらでヒアリングする」感覚が大事。
・BPR(業務プロセス改革)の視点で、業務フローのAS ISとTO BEを整理して、一部の業務フローをSaaSに置き換える。

【失敗4】自分がやった方が早い病

次は、「自分がやった方が早い病」です。プレイヤー時代に発症し、一度は寛解したものの、リーダーとしてCSチームを率いるようになってからも再発した失敗談です。

スライド37

【4-1】顧客のタスクの巻き取り

まずは対顧客から。初期のCarelyは、お客さん側で従業員情報をアップロードする機能がありませんでした。そのため、登録したい従業員情報をExcelで回収し、CSが代理でアップロードする運用をしていました。

そうすると、「ついでに残業時間もアップロードしてほしい」「ストレスチェックのリマインド送付もやっておいてほしい」と要望を伺うことがときどきあります。

「まぁ1時間ちょっとで終わる作業だし、やってあげるか」と、サッと作業を代行すると、めちゃめちゃ感謝されます。「田中さんのお陰で今年のストレスチェックは無事終えることができました！ありがとうございます。」と。嬉しくて、ついもっとやってあげたくなっちゃいます。このサイクルが罠でした。カウンセラーとクライアントの「共依存」に近い泥沼の関係性になってしまったのです…！

【顧客とCSの共依存サイクル】
顧客はCS担当にプロダクトの操作をお願いする
↓
CSが対応し感謝されることでよりタスクを巻き取ろうとしてしまう
↓
顧客がプロダクトを自律して使いこなそうとしなくなる
↓
顧客はCS担当にプロダクトの操作をお願いする

気づいた頃には、Carelyの操作は全部CSが巻き取ってあげていて、CS担当がべったりくっついていないと日々の業務が進まない状態になっていました。この頃は、「作業代行による短期的なプロダクトの利用促進」と「顧客の自律促進による持続的なテックタッチの仕組み構築」のトレードオフが最大の課題でした。やはり自分がやった方が早いからと言ってタスクを巻き取ることは、短期的な成果にしかならないため、「どこまでは巻き取ってOKなのか」線引きを明確にすることが大切だと学びました。

【4-2】チームのタスクの巻き取り

しばらくして、CSチームを率いるようになって、新入社員をチームに迎えいれるとき、自分がやった方が早い病が再発しました。過保護な親のように、事前に関係各所にお膳立てをして、成功体験を積んでもらえるよう必死に線路を敷いていました。これは過干渉すぎて、失敗に弱いチーム、リーダー依存のチームを創る結果になりました。

過干渉もダメだし、突き放して無関心もダメ。ちょうど良いバランスで、「課題の難易度」と「相手のケイパビリティ(能力×工数)」の掛け算で「自分の介入度合い」の見極めをする視点が必要なんだなということを学びました。

人間というのは、自分が仕事をしている感に安心したい生き物のようです。気をつけないとなぁ。

【失敗からの学び】
・顧客から作業を巻き取って短期的な成功を早めても、それは持続しない。
・Get things done through othersの視点を常に持つ。顧客に対しても、仲間に対しても。
・CSチームを率いるには、CSのCSとして仲間の成功に伴走する姿勢が求められる。

【失敗5】無茶が生んだ属人性

CSとして「期待値を超えろ」というクレドを掲げてお客さんへの提供価値を高める努力をしていました。その中でも1社、めちゃめちゃ注力していた企業でやってしまった失敗です。

海外法人と日本法人の人事機能の合理的な分担についてや、福利厚生の制度設計についてなど、プロダクトとは直接関係のないところも含めて課題解決をサポートし、極端なハイタッチをしていました。結果として、ぶっちぎりの成功事例を残すことができました。

しかし、想定していなかった問題がのちのち起こったのです。顧客の期待値があがりすぎたせいか、「あれもやってほしいので見積りしてください」「これはできないですか？」とあらゆる業務の依頼をされるようになってしまったのです。「さすがにできない」とお断りすることがほとんどでした。

スライド38

また、僕が現場を離れて担当を引き継いだ後にも、あがりすぎた期待値はそのままなので、難しい要求の対応に困ることが頻発してしまいました。

外れ値的な価値提供をすることは、やはり危険です。前提を超えない範囲内で、なるべく再現する勝ち方でがんばることが大切です。例えば、僕は女子ソフトボール日本代表の試合を見るのが好きなのですが、「上野さんがピッチャーとして完封すれば、勝てるチーム」というのは上野さんが抜けたら勝てなくなってしまいます。本当に強い組織とは、上野さんが怪我をしても、引退しても、どんな相手にも再現性高く勝てる組織です。

この経験から、属人的な目先の勝利より、再現する未来の勝利を大切にするようになりました。

【失敗からの学び】
・あまりにも無茶なサポートや、前提を超えた価値提供は属人性を生んでしまうので危険。
・「運用でカバーする」という魔法のセリフも、あとあと本当に後悔しないかを慎重に考える。
・再現性の高い「勝ち方」にこだわることで、強いCS組織を創れる。

【失敗6】改善要望依存症

次は顧客からのプロダクトに対するフィードバック回収についてです。CSがお客さんから機能の改善要望をいただくことは多々あります。「こんな機能がほしいです」と伺って、それを開発チームに共有し、リリースしたのでドヤ顔でお客さんに連絡したら、ショッキングな展開をむかえました。

CS：「◯◯さんがほしいっていってたこの機能、開発して先日リリースされました！」
顧客：「なんか思ってたんと違う。」

これ冗談抜きにまじで起こるから怖いよね。Githubにissue立てたの自分な手前、リリース後に改善依頼をまた出すのは土下座したい気分でした。

スライド39

忙しかったことに言い訳して、お客さんからメールでもらった改善要望を、そのままコピペして開発チームに伝えたり、すぐGOサインが出たものは詳細の要求定義をしないままGithubにissueを立てたりしていました。当然ですがお客さんは自分のニーズを話します。「他社が同じ悩みを持っているか」、「他社のユーザーも使えるか」ということは普通考えません。だからこそ、顧客からの改善要望を鵜呑みにせずに、CSが要求定義と汎用性を整理して言葉にしないといけないわけです。

必ず「課題と解決策(＝開発しようとしている機能)が何なのか」、「100社、200社とクライアント数が増えた時に汎用性のある課題と解決策なのか？」を言語化した上で開発チームへフィードバックする姿勢が不可欠だということを学びました。

【失敗からの学び】
・顧客からの改善要望を鵜呑みにしてはいけない。
・必ず「課題と解決策」×「他社での汎用性」を言語化してから、開発チームに仮説をぶつける。

【失敗7】工数削減という名の怠慢

CSの膨張しすぎたオペレーション工数を圧縮するために、ECRS(イクルス)のフレームワークであらゆるオペレーションの現状を分析し、削れる無駄を徹底的に削っていた時期がありました。8割型うまくいったのですが、残りあと一歩のところで甘かったと反省していることがあります。

スライド40

テックタッチの本質は、「より少なく、よりよく」です。顧客のほとんどは問い合わせしないで済むことを求めています。ユーザーがつまずく前に、レールを敷いて小石を取り除きそっと見守り、転びそうになったらすかさず道案内をするわけです。そのため、「最小工数、最大成果」をテーマにプロジェクトを推進していました。

画像11

既存機能の変更、サービスのルールやオペレーションフローの変更をするときに、必ず発生するのが「既存のお客さんへの説明責任を果たすこと」です。「去年はこうだったじゃないか！」と、特に初期のお客さんについて、業務フローの変更をネガティブに受け取られやすく、トラブルに発展するケースが何件か発生してしまいました。工数削減に目が行き過ぎていて、「◯時間削減できた！」という成果ばかりにとらわれて、実際にお客さんがどう感じるのか？への配慮が甘かったなと反省しました。テックタッチは顧客の深い理解があって、はじめて実現できるものと学びました。

【失敗からの学び】
・テックタッチの本質は、より少なく、より良く。「より良く」の視点を絶対に忘れてはいけない。
・顧客理解をあきらめたテックタッチは、ただの手抜き。
・攻めと守りのバランス大事。トラブルや突然の解約が起きないように「既存顧客への説明責任」を果たしながらも、攻める。

【失敗8】部門間の戦争

社内でも一定のプレゼンスを発揮できるようになってきたとき、僕は問題児になりました。端的に言うと周囲に求める期待値が高すぎて、部門間の衝突を生む人間になっていました。

スライド41

当時の僕はこんなことを考えていました。

「自社のプロダクトの機能やオペレーションを理解せずに営業するとかありえない。」
「CSに確認もなく大きな仕様変更のリリースをするとかありえない。」
「その意思決定、あのお客さんが絶対困るでしょ！」
「そんな無茶な要件で受注したら運用破綻しかねない！」

SaaSの組織構造の特性上、広く全体像を見れてしまうのがCSです。顧客とプロダクトを1番よく理解していて、最初に生のユーザーからのフィードバックを回収できる特権を持っています。目の前の顧客が困っているのをエモーショナルなところも含めて追体験できてしまうのがCSです。だからこそ、いろいろ気になることがたくさん出てきます。

最初はどうその問題意識を昇華したらいいのかわからず、とりあえず闇雲に憤りをぶつけていました。受注が決まったら営業にちょい厳し目のフィードバックをして、新機能がリリースされたら開発チームにちょいツンツンしたフィードバックをして、上長にも常にキレているという、カンニング竹山さんみたいなキレキャラでした。でもそうするとうまくいかないんですね。

「これくらいできて当たり前」という自分の中の常識を勝手に持っていたことが原因だと気づいて、それからは部門ごとの価値指標や背景を理解することに徹したり、DESC法を用いてアサーティブなコミュニケーションスタイルに変更したり、期待しないけど期待するスタンスに切り替えたりしていきました。

CSの役割

「開発（技術）」と「経営」をつなぐ結節点になることが、業務（オペレーション）に責任を持ち、顧客とプロダクトに最前線で向き合うCSが果たすべき役割です。顧客の成功のために、他部門の成功にも伴走する姿勢が必要なんだなと思いました。

【失敗からの学び】
・他部門の成功にも伴走して、初めて顧客の成功にたどり着ける。
・自分の常識≠他人の常識。

顧客も、仲間も成功に導く伴走者

ここ2年ちょっとCSとしてばりばり仕事してきたのですが2021年2月から事業推進部に異動してCSを離れることになったので、CSとしての失敗談をまとめてみました。何度も失敗して、担当したお客さんに解約されるという悔しい思いも経験して、その度に内的要因を分析し「次の顧客は絶対成功させるぞ」と誓い、改善を続けてきたんだなぁと、担当した1社1社での記憶を想い出すいい機会でした。

カスタマーサクセスというのは職種の名前であると同時に、「顧客を成功させることで持続的に収益をあげていくことを目指す経営哲学」でもあります。部門としてのCSだけががんばっても達成できず、開発チームも、セールスも、コーポレートも含めて、全社が「顧客の成功」というゴールに向けてベクトルが揃うことではじめて実現できるものです。

職種としての「カスタマーサクセス」ではなくなりましたが、顧客も仲間も成功に導く伴走者として、これからもカスタマーサクセスを目指していこうと思います！

CSとしてバイブルにしているオススメの本たち
・ALL for SaaS SaaS立ち上げのすべて（SaaSのすべて！）
・カスタマーサクセス（いわゆる青本！）
・カスタマーサクセスとは何か（いわゆる赤本！）
・THE MODEL（いわゆる黒本！）
・ネット・プロモーター経営（NPSの原点！）
・イシューからはじめよ（顧客の課題を的確に捉える！）
・起業の科学（スタートアップでの事業の創り方！）

このnoteがおもしろかったら、ハートマークの「スキ」をクリックいただけると励みになるので嬉しいです！ぜひ、CSの仲間にもシェアしてください〜。

※その後iCAREは退職し、2022年3月に株式会社パパゲーノという会社を設立して、メンタルヘルス分野で起業しています。メンタルヘルスに興味ある方とぜひ繋がりたいので、興味ある方はDMいただけると嬉しいです。


この記事が気に入ったらサポートをしてみませんか？