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

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

産業保健×SaaSの特徴

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【失敗8】部門間の戦争

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

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

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

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

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

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

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

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

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

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

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

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