SaaS有償支援サービス立ち上げの1年の全記録と厳選23TIPS

私は2018年～2019年後半にかけて、弊社で提供しているUX企画支援SaaS、USERGRAMの有償支援サービス立ち上げにゼロから関わっていました。その時の経験とそこから得た気づきを、

・有償支援サービスの立ち上げを検討されている方
・既に有償支援サービスの提供を開始している方

に少しでも参考になればと思い、また自分用の整理も兼ねて、本記事に余すことなく全てまとめました（2万7千字になっちゃったｗ）。

SaaS事業における有償支援サービスはプロフェッショナルサービス、通称PSなどと言われたりもしますが、PSについての全体像やトレンドはReproのNaoki Itoさんの2019年12月の記事がめちゃくちゃまとまってますので是非！

（因みに本記事で扱う有償支援サービスとは、上記伊藤さんの記事でいうところの「b-1. ツールに紐づくPS」に該当します！）

さて、記事の構成ですが
第1章：全てが手探り！立ち上げ～運用ストーリー
第2章：SaaSで有償支援サービスを提供する3つのメリット&注意点
第3章：有償支援サービス成功の厳選23TIPS（立ち上げとデリバリ）
の3章構成となっております。

それでは本編へどうぞー。

※注意：本記事の内容は、全て2018・2019年当時の状況なので、現在は状況が変わっている部分も多分にありますのでその点はご留意くださいませ。

■第1章：全てが手探り！立ち上げ～運用ストーリー

セールスから有償支援サービス立ち上げ責任者への異動

そもそもなぜ私が、有償支援サービスの立ち上げに関わることになったのか。事の始まりは2018年でした。当時私はSaaS・コンサルの統合セールス（フィールドセールス）をやっていたのですが、ある日唐突に上司陣(4名)に呼び出されてこう告げられたのです。

「カスタマーサクセス（CS）に本格的に人員を張るので異動してほしい。そしてCSの中で礒野さんには有償支援サービス立ち上げの責任者の役割を担ってほしい」

と。最初からCSで有償支援サービスを立ち上げることは決まっていたというなんとも受動的なきっかけでしたｗ

当時はCSチームもまだ4名(実働2名)しかおらず、効果的なオンボーディングプロセスもまだ確立されていないがクライアントは150社以上支援中というある意味で非常にチャレンジングな状態でした。当時打診を受けた私の心境としては「セールスも段々と軌道に乗ってきたタイミングで本当にCSに異動してもよいものか」という感じだったのですが、1週間考えた末「セールスもCSもSaaSの支援という意味でやっていることは同じ。それに立ち上げの責任者ってやりがいがありそう！」という結論に至り、前向きにこの機会に挑戦することに決めました。

なぜ有償支援を立ち上げるのか？

上記経緯があるので、立ち上げの理由は私目線だと「立ち上げることが決まっていから」という感じでした

何ならその2018年内の有償支援サービスの目標提供本数まで決まっていましたからね。

ただ最初のきっかけこそ受動的でしたが「立ち上げることになったからには、自分なりに何のためにやるのかを定義しておかねば」と考えました。色々な人に話を聞いて思案した結論として「SaaS活用の成功事例を生み出す支援の方法を検証するため」というのが、有償支援サービス立ち上げの理由に最もしっくりくると当時結論づけました。

当時のチーム状況と支援方法論(β版)の存在
USERGRAMがリリースされたのは2017年なのですが、その当時はまだ成功事例などは出ていなかったので、事例を作るための超ハイタッチ特任チーム(1-2名)が、リリースとほぼ同時に組成されていました。

1年間に及ぶそのチームの活躍もあり、私がCSにジョインする直前である2018年の前半には、幾つかの成功事例と支援方法論(β版)が出来上がるところまではこぎつけていたのです。ただしそれは特任チームがかなりの工数をかけて実践していたことなので、

・他の人でも実践可能なのか
・他の企業に提供しても同じように成功事例が生まれるのか

はまだ未知数な状況でした。一方で当時の特任チームおよびCS責任者は「この支援は値段をつけても絶対にニーズとバリューがあるに違いない」とも確信していました。

こういった状況を踏まえ、その方法論の再現性を「他の企業」で「他の担当」が実施しながら検証することになったというのが有償支援サービス立ち上げの経緯だったのです（後から色々な人に聞いて解釈しました）。

そもそもUSERGRAMをリリースしたのも、企業のニーズがUXに関するスポット支援（コンサル）から自社での運用ニーズ（内製化・インハウス化）へと移行していることに対応するものだったので、この方法論で成功事例を量産していけると証明できれば事業が大きく前進します。こういう背景を踏まえて有償サービス立ち上げの目的は「SaaS活用の成功事例を生み出す支援の方法論の検証」と私なりに再度位置付けました。

事業から見た立ち上げのもう1つの理由

メインの理由は上記とした上で、サブにもう1つ目的があったと思っています。ここからは推測も入りますが、事業観点でいうと有償支援サービスが売上の柱として採算が見込めるかどうかを早めに検証するのが大事だったんだろうなと。当時2018年度時点の2019年度事業計画には、この有償支援サービスを安定的に走らせる計画が組み込まれていたので、それを2018年中に検証するPoC的な側面もありました。

有償での支援にニーズがあり複数の企業で安定的にデリバリするとなれば採用計画も変わってきますし、売上のポートフォリオも変更が必要になる。一方で何らかの理由（主にニーズorケイパビリティ）で事業としての拡大が難しいとなれば、それを踏まえた上で事業計画を立てる必要があります。こういったインプットを早期に収集するために2018年の立ち上げトライアルが重要な位置づけになると自分の中でも意識していました。

支援方法論(β版)の読み込み

さて、目的も明確になったところでいよいよ始動です。手元にあるのは支援方法論(β版)とチームメンバー2名（私＋1名）という状態で他はなにも有りません。なのでひとまずメンバーと方法論(β版)を読み込んでみると、サービスの立て付けは下記のように決まっていました。

【有償支援サービスの最初の立て付け】
・USERGRAMを利用している顧客が対象
・最低6ヶ月間の支援(打ち合わせ頻度は月1～2回)
・期待形成フェーズ(2ヶ月)と個人スキルアップフェーズ(4ヶ月)

逆に上記以外の、どんな価値がありそうか、誰に売れるのか（USERGRAMを提供していない顧客にも前走りで提供しうるのか）、支援にあたってどんな能力が必要なのか等は全く不明確だったので、とりあえずこの立て付けで役に立てそうと思える企業様に色々とご提案することから始めました。

試行錯誤1：誰の役に立つのか

【ターゲット顧客仮説を立てる】
幸い自分はその前にフィールドセールスを半年ほど経験していたり、それより前は5年間のコンサルティング経験で数多くのお客様のUXコンサルティングのご支援にあたっていたので顧客ニーズについての勘所はありました。方法論が示す有償支援サービスの立て付けから逆算し

1.USERGRAMを利用中or利用開始予定
2.スポットではなく長期の支援を求めている
3.自社でデジタルマーケを内製したいと思っている（≠運用の代理）

という条件に当てはまりそうな顧客には役立てそうと考えてリストアップ（5～8社くらい）し、お客様へのご相談を順次開始していきました。ただ特に確信などはなく、一番可能性が高そうなところにあたったという程度なので、正直不安はかなり大きかったです。

因みに最初にこの3の「内製ニーズ」を条件をリストアップしたのは、前述の通りUSERGRAM自体が企業におけるUX企画の内製化を支援するSaaSであること、そしてUX企画をアウトソースするニーズに対しては別途コンサルティングのサービスを既に提供していたことの2つが大きいです。

通常のSaaS企業として有償サービスを検討すると、例えばReproさんのASOサービスのようにツールの支援領域と直接関係ないがクライアントのニーズがある領域や、ツールの運用代行を検討されるケースも多いと思うのですが、最初からそこはスコープアウトして検討していきました。

【提案・営業は自分の足で】
ターゲット顧客仮設を立てた後の提案・相談活動は積極的に自分の足で行いましたがこれはサービス立ち上げフェーズにおいてとても重要だったと後から振り返って思います。

当時本プロダクトであるUSERGRAMのフィールドセールスメンバーも居たので、有償支援サービスの営業活動にあたってそのメンバーの協力を得ることはもちろん可能でした（実際一部では協力を依頼して了承も貰っていました）。が、まだ有償支援サービス自体は実績も何もないし、かつUSERGRAMのセールスすら確固たる方法論が確立されていなかった当時において、有償サービスの営業をフィールドセールスに全面的にお願いするのは状況的に厳しい（＝任せていても結果が出るとは限らない）だろうと判断し、自分が直接営業にコミットすることを強く意識しました。

こうやって自らが営業活動に回り顧客の話を聞くことで、自分の仮説がスピーディーにブラッシュアップされていき、サービスの方向性を考えるにあたってのインプットを早期にたくさん得ることが出来ました。

【手探りながらも進めたことで結果が生まれる】
自分で営業活動を行ったことは結果にも活きました。結果的にリストアップしていった企業様から、開始3ヶ月で複数のご発注を頂けたのです。

やはり営業とは「意志なき者には売れない」という世界だと思うので、立ち上げサービスという揺蕩った状態であるからこそ自分が責任を持ち、役に立つんだという覚悟で活動をしていたことは、この結果と関係がなかったとは思っていません。

ご発注を頂けたポイントとして、有償支援サービスという立て付けは守りつつも、企業の状況に応じて目的やゴール設定の表現についてはカスタマイズしてご提案したことが挙げられると思います。方法論の検証なので実際の支援内容については大幅に変更することは難しかったのですが「その支援を何のためにやるのか」「支援終了時にどういう状況でいたいか」というところを徹底的に個別の企業視点で提案したことで共感いただけた、それが最終的にご発注繋がったと感じています。

ちなみに結果的に受注を頂いた企業様は、当初のターゲット仮説3つには合致していたのですが、想定していた状況は大きく異なっていました。元々は「データ活用の取り組みが一巡しており非線形の進化を求める中でUX企画に着目する顧客」向けと考えていたのですが、実態としては「これからデータ活用やUX企画に取り組みたいが自分たちにノウハウがなく外部からの初期教育を求める顧客」からのご発注がとても多かったのです。

このように営業活動を進めていくことで、自分たちの立ち上げたいサービスが一体どんな顧客のどんな状況に役立つか、ということがアップデートされていくのも営業活動を進めた果実でした。これを机の上だけでうんうん唸って、体裁ばかりの顧客ヒアリングを繰り返していても、おそらく一向にアップデートはされなかったと思います。

誰に売れるのかを知りたければ、実際買ってくれる人が現れるまで売り続ける、売れてからターゲットについて考える方が効率が良いなと実感しました（実践機会がないとそもそも支援のブラッシュアップも何も出来ないですしね）。

試行錯誤2：どんな支援をするか

さて、受注できたら今度はデリバリ（支援）です。支援方法論(β版)があったので、まずはそれに沿って支援していくことを主眼に置きましたが、とはいえその通りにやってうまくいく保証はどこにもないので、方法論はベースに置きつつ、上手くいかないことはその場で考え対処するという方針で進めていきました。

【適切な対象者が分からない】
最初にぶつかったのはこの壁でした。支援の対象と出来るのは4人程度というのが方法論にあったので、クライアントに対象となる4名の方を選んで貰う必要があったのです。

ただクライアントに「どの様な人が参加者として向いていますでしょうか？」と言われても、知見が無いので「やる気のある人が良いです！」という当たり前の回答しか出来ませんでした。本来は

・リーダー or 現場担当？
・企画側の人 or 実行側の人？
・4人が限界 or 本当は多い方が良い？
・同じ部署同士 or 違う部署も混ぜる？
・長く部署にいる人 or 最近入ったばかりの人？

みたいな観点で答えるべきだったと思うのですがそれも手探りで。1社1社でトライ&エラーを繰り返しながら除々に確立していったというのが実情でした。その初期仮説として「やる気のある人」というのは、そこまで間違っていなかったかなとは思いますが(笑)。

実際支援を進めていくと、やる気に関わらず習熟度に明確な差が生まれるケースも散見されたため、必ずその都度分析と振り返りを行いながら、それは何故なのか、どういう人であれば吸収が早くなるのか、などの知見をゼロから溜めていきました。

その結果、弊社のSaaSの有償支援サービスに固有の話ですが
・マーケ施策を実際に打っている人の方が成長が早い
・上長は必ず巻き込むべき
・巻き込む人数は多いほうが最終的に活動が大きくなる
といった知見を得ることが出来ていきました

幸いなことに頂いた受注がそれぞれ時期がちょっとずつズレていたため（同時に開始ではなかったので）、1つの支援で得られた知見をすぐに次のプロジェクトにて活かすという形で高速にアップデートを繰り返していきました。1つ1つのプロジェクトの立ち上げに集中するべく時期はあえてずらしていましたが、思った以上にそれに助けられました（というかそれが無かったら詰んでましたね）。

【期待値立ち上げ・スキルアップ方法論もPDCA】
有償支援サービスが通常のオンボーディングと違うのはその期間の長さです。通常のオンボーディングは一度きり＋オンボーディング後の経過を体感しづらいという点がありますが、有償支援サービスの場合は顧客に深く入り込みフォローすることができるので、より顧客の状況に合わせて色々な支援をご提供することが可能です。

SaaSで最も重要なのは「顧客の適切な期待値とやる気」だと思っているのですが、その期待値をどう立ち上げるのかという点でもこの環境が活きました。有償支援サービスのトライアルの中で方法論通りに座学や世界観の説明などでの期待値立ち上げも実施したのですが、それだけで上手くいくかどうかわからなかったので、追加で実際にクライアントが実行しているメルマガやキャンペーンをテーマに分析〜改善までを一緒に体感するワークショップ、通称「基礎ワークショップ」をトライアル実施したのですが、座学よりもこの基礎ワークショップの方が顧客の理解度が圧倒的に高まることがこの有償支援サービスの試行錯誤の中でわかってきたのです。

本来こういった取り組みは

・トライアルなので新しく作るのは時間がかかる
・成功するかわからないのでリスクが高い
・顧客理解が浅いと適切に提供できない

といった事情があり、なかなか通常の支援では実施できないものです。しかし有償支援ではこの辺をクリアすることができるので、適切にリスクをとってより顧客にとって意味があるご支援を提供することができました。

スキルアップの方法論も同様です。当初の支援方法論ではマンツーマンで顧客の分析・企画に対してフィードバックするということでフィードバック内容をまとめたシートを作ってお渡しするということをしていましたが、実際にトライアルしてみると、なかなか顧客に伝わっていない、伝わったにしてもスキルアップにつながらないということが起こりました。

そんな時に、フィードバックシートを作る前に、顧客が実際に作った企画書の内容や観察内容をチェックする時に社内作業用に作っていた赤入れシートをたまたま顧客に見せたら「え、いつものフィードバックシートよりこっちの赤入れシートの方が見る気になるし分かりやすい！こっちをもらえないですか？」と言われ、そのままお渡ししたところこれが好評だったんですね。しかもその赤ペンシートをお渡しすることで、顧客の企画スキルがみるみる上がっていった。

こういう積み重ねやちょっとした気づきにより支援をアップデートさせられたのも、何をすれば期待値立ち上げやスキルアップに繋がるのかということがわからない中、深い顧客理解と通常よりも長い時間、顧客のフィードバックを得やすい環境にあったからこそだなと思っています。

こういった積み重ねの中で「期待値の立ち上げ方」「スキルアップ方法論」だけでなく「良い企画作り」「社内での研修方法」などのニーズに対応するための方法論も確立されていきました。

【成果創出や定着に結びつくかが最重要判断軸】
何をやっていいかは手探りでやっていくことが多いために、アイデアを出すのも実行することを決める時にも迷うことは星の数ほどあります。そんな時に方向性を見失わないように、自分たちが試したいことではなく「その時の顧客にとって意味があること、成果や半年後の定着に向いた活動になっているか、顧客の課題を解決するベクトルを向いているか」を常に判断基準にして意思決定していきました。

実際に色々な支援を試せる状況になると、仕入れた知識で他社がやっているカスタマーサクセスのやり方などを取り入れてみたくなりますが、自分たちが向き合っている目の前の顧客にはフィットしないということも数多くありますし、短期的には良いけど長期的な顧客の方向性を考えるとやるべきでないこともあります。例えばこちらでお手本の企画を作る、といったアイデアも出るわけですが、それは顧客の定着に向かってないよね、ということで実際に却下したりしていました。

必ず顧客の成果、定着を向いて支援内容を考えるということを徹底したことで、トライアルはするものの支援の方向性がブレるということを防げました。

【他の人でもデリバリ出来るかを次に問う】
最後に気をつけていてよかったのは、トライアルで実施することが多いとはいえ、そもそも有償支援の立ち上げの目的が「成功事例を生み出す支援の方法を検証するため」だったため、その場の特殊な環境でしか通用しないような支援はやらない、ということは制約の一つとして設けていました。

例えば、デリバリに関わっている自分やメンバーの特殊なスキルに依存するもの（自分で言えばコンサル経験など、他の社員で実施が困難そうと考えられるもの）や、特殊な顧客の状況を解決する施策（他企業ではあまり発生しないだろうというもの）などですね。こういったものはその場その場の支援でどうしても必要であれば実施しますが、サービスのスタンダードを作るという観点からは、プロセスに対しても結果に対しても歪んだインプットとなるのでなるべく実施しないに越したことはありません。

実際に直面したのは「自分たちと一緒に施策や企画を考えてほしい（コンサルして欲しい）」という声や「USERGRAMだけではなく他ツールの使い方も指導してほしい」といった声でした。これらにどのように対応するのか、というのは当時非常に悩んだ部分ではありました。

が、自分では対応できたとしても、CSチームメンバーで対応できるかというと難しいと考えられる部分については、断腸の思いでサービスのコミットラインをお伝えし、別の解決方法をご提示するようにしていました。（チーム全体のレベルがアップしていけばこれらも解決するスコープに入ってくると思いますが、あくまで当時はという意味です。）

こういう状況に直面した際は「未来でもこういうことが発生した際に、ケイパビリティも含め自社としてどういう対応があるべきなのか。今だけではなく、その未来も含めたスタンダードを作っているんだ」という気持ちで対処することが重要だと思います。特にサービスの立ち上げ期は。

目の前の顧客の満足度については、サービスのスタンダード作りとは別の形で対応するという線引きが明確であれば、個別に対応するのもアリかとは思いますが、現実的にはやらないほうが互いに良い状態になるかとは思います。

こういったデリバリの試行錯誤の結果もあり、1つのプロジェクトが終わる、あるいは中盤に差し掛かる辺りで、クライアントの社内でUX企画が定着に繋がったり成果が実際に創出される例が複数生まれるようになりました。ここまでで、当初の目的としていた「成果が創出される支援方法論の検証」は、かなり高い度合いで達成できていました。

試行錯誤3：サービスの価値が不明確

【サービスの価値定義をする意味】
さて、営業やデリバリの試行錯誤を経て徐々にクライアントでの成果も出てきたので、立ち上げの最終フェーズとして型化や拡大に向けた整理をしていた時に苦労したのがこの「サービスの価値を何と定義するか」ということでした。

確かに様々な試行錯誤を経てクライアントの役には立つし、社員をトレーニングして拡大提供できそうな目処は立っていたのですが「それにどんな価値があるのか」ということが対社内でも対クライアントでも認識が揃っていないと、容易に期待値ズレが起こり各所にご迷惑をおかけすることになります。なので有償支援サービスに一体どういう価値があると「定義」するのか。これが立ち上げの最後の壁となりました。

【通常の支援と何が違うんでしたっけ？】
まず説明したのは拡大の要が営業ということでセールスだったのですが、まずここでサービス価値を理解してもらうことに苦戦しました。当時、同時並行で「スタートダッシュプログラム」という3ヶ月のオンボーディングプログラム（追加料金不要）も完成させ稼働開始していたため「スタートダッシュプログラムと有償支援サービスは根本的に何が違うのか」という問いに答える必要がありました。確かにセールスとしては、日々相対する顧客に価値を説明し適切な支援を提案しなければならないので、この違いをしっかり理解する必要があります。

しかしその当時ゼロからサービスを立ち上げていた自分としては、有償支援サービスにどっぷりと浸かりすぎていたので「え、この2つは全然違うじゃん。むしろ何がわからないの？」と感じてしまったのも事実でした。正直、かなり一次情報量の差があるなと。半年に亘ってクライアントと接してその変化や成果を目の当たりにしていた自分としては、その質が全く異なることが当たり前だったのですが、側から見ていると、期間が6ヶ月で有償であること以外の違いが何なのか見えづらくなっていたのでした。これは社内の問題ではなく、自分自身がその差異を言語化できていないことが大きな課題だと感じました。

当時、この有償支援サービスが立ち上がり成果が見えてきたタイミングで、急いでこの違いについて説明せよと言われていたこともあり、当時メンバーで2日間程度徹底議論して、何が本質的な違いなのかを議論しました。

【違いはプロセスと結果で考える】
違いについては、①プロセスがどう異なるのか、②その結果として得られる価値がどう違うのか、という2つに分けて考えました（因みに顧客に話す際は、結果→プロセスの順で話すのですが）。

まず①プロセスについては期間は明確な差異ですがそれだけでは説明になりません。期間はもちろん異なるのですが、支援していてクライアント内で本質的起こる変化は何か。メンバーと議論した結果たどり着いたのは、企画に関する試行錯誤の回数が4〜5倍程度に増えるため、企画の練度が高まりきり実行→振り返りが定着すること、そしての試行錯誤の回数結果通常の施策の運用とは違う新しい企画に繋がっていくこと、がプロセスとして生まれる大きな違いになっていそうでした。

そして②結果として得られる価値については実際に顧客に聞いてみました。面白かったのは顧客によって価値を感じているポイントが違ったことです。

「企画の質が変わった」
「自信を持って提案できるようになった。」
「社員の尻を叩いてくれてUX企画の文化が根付いた」

などなど。最初は「定着」や「成果創出」がメインの価値かと思ったのですが、色々と解きほぐしていくに「自社の社員を教育したい」というニーズに最もマッチしている、その結果として社員である顧客が成長し、文化に根付いたり成果が創出されていると考えるのがコミットラインとしても適切な感じがありそうでした。

成果創出や定着といった価値は、弊社でSaaSの運用代理はしないというスタンスだったこと、つまり実際に成果を出すのも定着させるのも最後はクライアントであることを踏まえると、コミットラインとして置くのは難しかったんですね。なので教育サービスというプロセスそのものをコミットラインとして置くことで、期待値を適切に立ち上げる方向にしました。

そう考えると追加料金不要のスタートダッシュプログラムは、有償支援で目指す「教育」というよりも、あくまで使い方を覚えるというところまでのインストールなので、質は全然違うし目指すゴールも全く違うということを受け入れていただけるようになりました。スタートダッシュの途中から有償に切り替えられるのか？というのもNoです。なぜなら最初から目指している方向性が違うからですね。

【顧客への説明は事例が一番】
上記は社内向けの整理でしたが、顧客向けの説明は概念レベルではすんなりと受け入れて頂けました（サービスの違いも含め）。ただし結局一番刺さりが良かったのはサービスの提供事例で、そこは実際この有償支援サービスを提供した人の方が雄弁にかつ生々しく語れるだろうということで、有償支援サービスに興味を持って頂いた顧客への説明には、自分や立ち上げに関わっていたメンバーもなるべく同席するようにしています。

その中ではやはり顧客のbefore / after、つまり「最初はこうだった社員が最後にはこんな状態になった」というのを、途中のつまづきやそれらをどう解消していったか、ということを生々しく経過も含めて語ることで、顧客からも共感を得ることができました。「おーそれならうちの社員でもできるかもしれないね」という感じで。

このような概念（プロセス＋結果）と事例のセットにより、提供価値についても社内外の理解を得られるようになりました。

立ち上げから運用へ：責任者の育成

立ち上げの仕上げはこの有償支援を提供していける責任者の育成です。支援を「責任者＋専属トレーナー（＝カスタマーサクセス）」という2名体制で実施することにしていたので、必然的にこの責任者を育成できるかどうかがサービスラインの上限になります。

このあたりはコンサルにおけるマネジャーの数がプロジェクトの本数（＝売上）を決める、という発想と一緒ですね。

責任者になるに当たっては、やはりこの有償支援を何本か最後までデリバリし切っていることが望ましいのでその視点で一緒にデリバリしていたメンバーが責任者になれるように、ということを常に意識していました。トレーナーとして支援をする立場からその責任者になるに当たっては

1. ゴールに向けた長期的計画を立てられるか
2. クライアントをクライアント以上に理解して対話できるか
3. 自社トレーナーに適切にフィードバックできるか

という3点が主なハードルになります。早期から育成に向けて自分の責任者をやっているプロジェクトで擬似的に責任者ロールをやってもらうことをやっていました。自分がプロジェクトから離れない前提で、上記の3点をトライしてもらい、つまり一時的にプロジェクトメンバーが3人になった状態で、クライアントの前での発言や社内でのフィードバックに至るまで、とにかく実践＋細かく振り返り、というセットをやりました。

約3ヶ月ほどの責任者トレーニングを経てあとは手を離しての実践あるのみ、という状態になれば、実プロジェクトで自分がいない状態で責任者ロールをやってもらっています。もちろん都度問題が出ることもあるのですが、そこの相談には徹底的に乗ってあげる前提で、実践機会を積んでもらいます。いつまでも自分が関わっていては、矢面に立つヒリヒリ感を感じられません。そしてそれなしに成長はできないので、早いタイミングでこのシーンを体感してもらうことを優先しています。

今では、無事に自分以外の責任者も育ち、完全に自分から手離れして有償支援サービスそのものの運営もバトンタッチし定常的に運営される状態になっています。

立ち上げ～運用バトンタッチまで約1年程度でしたが、振り返ってみるとやはり最初の3ヶ月～半年のウェイトが大きかったですね。営業からデリバリPDCA、そして提供価値の定義も殆どが最初の3・4ヶ月に行ったことなので、そこでいかに成功の感触を掴み社内に還元できるか。それがポイントだったなと思います。

■第2章：SaaSで有償支援サービスを提供する3つのメリット&注意点

さて第1章では立ち上げの苦労とストーリーを書いてきましたが、第2章ではその立ち上げの経験からSaaS事業で有償支援サービスを実施するとどんなメリットがあるのか、立ち上げる際に誤解されやすい点についてまとめておきます。

SaaSで有償支援サービスを実施する3つのメリット

結論から書くと

メリット1.特定クライアントの大成功
メリット2.CSプログラムの開発・強化
メリット3.メンバーの底上げ成長

という3つのメリットがあると認識しています。1つずつ解説していきます。

メリット1.特定クライアントの大成功

有償支援サービスの特徴は表面的に言ってしまえば

・支援の対価を頂いている
・契約期間が一定長くかつ定められている

という2点だと思うのですが、この2つによって生まれる効果は非常に大きいです。

【支援の対価】
まず支援への対価という部分ですが、社内的には通常の支援と比べて当然プレッシャーがかかることになります。通常のカスタマーサクセスでは力を抜いてやっているかというと全くそんなことはないのですが、対価を頂いていることで、そうでない時に比べて責任者やトレーナー個人に適切な緊張感が生まれるのはごく自然なことだと思っていますし、その結果として支援の質は高まりやすくなります。

そして、こちらの方が実は重要なのですが、クライアントのコミットメントが通常導入時に比べて極めて高くなります。これは対価を支払っているということからくるもので、社内の目線的には「金払ってるんだからしっかり学べよ」というプレッシャーがあるでしょうし、参加される方にとっても「せっかくの機会だからしっかり学び社内に還元しよう」という意識が生まれやすくなります。

SaaSはあくまでツールなので、支援する側にどれだけ意思があってもそれを使う側である顧客に意思がなければどんな素晴らしい支援も意味をなしません。その意味でクライアントにやる気がある、ということは最終的に生まれる成果を左右する要因の中でも非常にクリティカルなものの1つになってきます。これは有償支援サービスに限らず、どのSaaSの導入においても言えることだと思いますが。

その意味で有償支援サービスは、その性質上クライアントに自然とやる気が生まれやすい構造であると言えます。RIZAPや英語学習などでお金を払ったほうが本気度が高まるという現象と同じですね。

【契約期間が一定長くかつ定められている】
そしてもう1つが契約期間です。弊社の有償支援は最低を6か月として期間が定められていますが、他社の場合でも契約を締結する関係上期間が定められることがほとんどだと思いますし、結果的に一定の長い期間になるのではないかと思います。

契約期間が長いことで何が起こるかというと、

・トレーナーがクライアントをより深く理解できる
・トレーナーとクライアントの信頼関係が構築されやすい
・反応を踏まえて支援の路線をチューニングすることが可能

といった、通常の短い期間の支援では実現しづらいことができるようになります。クライアントをより深く理解することで、よりクライアントに刺さりやすい支援、コミュニケーションをアレンジすることが可能になりますし、信頼関係が構築されると相互のフィードバックがより率直なものになります。また支援の反応を踏まえて、より実効性の高い支援へと切り替えることも可能になります。

以上、支援の対価、そして契約期間という2つの特性があるため結果的に「トレーナーとクライアントの相互のコミットメント」がある中で「適切な支援を信頼関係の中で実行できる」ため、有償支援を実施した企業が成功する確率は極めて高くなります。企業側からするとお金を支払っているのだから当たり前、という感覚かもしれませんが、有償支援は提供している観点から見ると驚異的な成功率を誇っています。

また単なる成功事例ではなく、解像度がかなり高い（＝変化のプロセスを我々が仔細に把握している）かつ前例のない文字通りの大成功事例が生まれるので、マーケやセールスへの事例供給、カスタマーサクセス活動における他社横展開という観点でもポジティブな影響も非常に大きいです。特定クライアントの大成功、これが有償支援サービスのまず持ってわかりやすい1つ目のメリットになります。

メリット2.CSプログラムの開発・強化

2点目はCSプログラムの開発・強化です。有償支援サービスではクライアントと深い関係性がある上に期間が一定以上あるので、立ち上げのストーリーでもありましたが、クライアントの抱えている負や課題に対して、新しいソリューションをトライアルすることが可能です。

もちろんクライアントにはきちんとご提案の上で実行するのですが、新しいソリューションとは言え、クライアントの課題の解決を起点に考えているので、ほとんどの場合受け入れていただけます。やりながら、上手くいく方法を模索することが圧倒的に多いのですが、これまで有償支援の中で新規トライアルしてきたプログラムは、そのほとんどが支援の中では功を奏し、8割程度はその後通常のカスタマーサクセス支援の中にも取り入れています。

立ち上げストーリーの中で書いた、基礎ワークショップや赤ペン、より良い企画を立てるための企画書シート、社内研修を行うための教育キットなども今はスタンダード支援メニューの1つとして様々なお客様にご提供しており、その結果他企業でも成功が生まれています（今も有償支援サービスからは様々なトライアルが行われていて、その中から次々に新しい支援メニューが生まれています）。

このように、有償支援サービスの試行錯誤から新しい支援プログラムが生まれ、カスタマーサクセス全体としての支援力やソリューション力が上がるのが2つ目の有償支援のメリットです。カスタマーサクセスのソリューション力アップは、最終的にはそのソリューションがプロダクト化されることでプロダクトの強化にも繋がるので、2つ目のメリットは事業上も非常に大きな意味合いを持っています。

メリット3.メンバーの底上げ成長

3点目がメンバーの底上げ成長です。成長じゃないです。底上げ成長。

有償支援サービスは期間が一定長いので、SaaSにおいて最も重要な価値である、導入前後のクライアントのbefore/afterについて、通常支援よりも圧倒的にリアリティのある肌感を得ることができます。通常の支援だとオンボーディングの後はクライアントが自力で活用を頑張り、久々にお伺いした時には変わっているというケースが多いので、仮にどう変わったかは分かるにしても、その変化の裏にどのような苦労があったか、それに対してどのように支援すればよかったかということについてはわかりづらいものです。

有償支援サービスでは、クライアントの変革、個人スキルアップ、成果、組織的定着にまで並走して寄り添うことになるので、間近でその変革を目撃することができますし、またその変革に自分も一員となって関わることで自分ごととして話すことができるようになります。何より自分の行った支援のどれが効果的でどこが顧客にとってのターニングポイントになったのかということを生々しく理解することができます。

実はカスタマーサクセスの立場においても、このように1社と長期間深く関われる経験というのは意外と希少です。多数のクライアントを支援していたり、長期間だけれども頻度は多くなかったり、ということが一般的だと思います。それに比べると有償支援で積むことのできる体験やスキルアップはSaaSのカスタマーサクセスとして一段レベルアップする上で非常に良い機会であり、結果的にメンバーが線形でない進化を遂げることになります。

そのためにも弊社の場合、有償支援にメンバーがアサインされると、それに一定期間没頭できるように他の業務を調整し、意図的に工数をかけられる環境を作っています。またデリバリメンバーについてもあえて業務で分けて専任チームを作っていません。それもこのように良い成長の機会になるため、可能な限り色々なメンバーに経験を積んでほしいという狙いがあるためです（有償支援サービスの責任者だけはそうもいかないので専任のチームになっていますが）。

有償支援サービスを実施するときの注意点3つ

以上、色々とメリットの多い有償支援サービスですが、今私が振り返っていて、実施するにあたっていくつか押さえておくべき注意点があると思っていますのでそれも記載します。これも結論から書くと以下3点になります。

注意点1.通常支援と混同しやすい(特に社内)
注意点2.売り物じゃない＋セット売りは期待できない
注意点3.デリバリに上限をかけないと死ぬ

注意点1.通常支援と混同しやすい(特に社内)

これは立ち上げストーリーの中でも触れたポイントです。特に弊社の場合、という部分も多いとは思うのですが、運用代理をやると言ったわかりやすい違いがあったわけではないため、有償支援と通常支援でサービスがどう違うのかという点については、きちんと整理ができていないままデリバリを進めていた部分もあったので、社内的に多少混乱が起こってしまったことがありました。カスタマーサクセスメンバーについてもそうですし、セールスメンバーについても。

有償支援サービスを始めるとおそらく普通のCSとどう違うの？という話は必ず出ると思いますので、仮説であってもこう違うという点を明らかにした上で提供を開始していくのが良いと思います。

特にサービスの特性上、支援の中に深く入っていけばいくほど、自分では違いを当たり前のものとして認識する一方で社内で関わっていないメンバーとの認識の差は広がっていく構造にあります。なので自分の想像以上に認識の差は広がるのである、という前提で立ち上げを進めていき、必要に応じプロジェクトの状況やコンセプトについて適切にシェアしながら進めていくのがおすすめですね。

注意点2.売り物じゃない(セット売りは期待できない)

有償支援サービスをやっていて最も想定との乖離が大きかった気づきがこれですね。何かと言うと有償支援サービスは「顧客のニーズがあれば提供するもの＝商品・売り物」ではなく「提供側で適性を見極め、必要だと思った時に提案する武器の1つである」と認識すべきということでした。

自分も最初この感覚をつかむことができなかったのでこの違いを噛み砕いて書くと

商品として売る：売り上げ目標を持ち、情報を広く開示し提案していく。欲しいという顧客には基本的に提供するスタンスを取る。

武器として使う：売り上げ目標は持たない。自分たちが支援をしていて、必要だと感じた顧客にのみ提案する。時に断る。

ということになると思っています。立ち上げ理由のパートでも、当初事業計画として柱に入れることができるのかの検証というのもサブ目的の1つにあると書きましたが、結論から言うと「まだ柱として見込んではいけない」というのが私の検証結果でした。

カスタマーサクセスは顧客を支援しサクセスしていただくことがミッションなので、支援そのものを商品として扱い目標を立ててしまうと、不適切な支援でも進めてしまいかねない。意思を持って顧客のサクセスまでのロードマップを引き、自ら支援内容を提案するというハンドリングをしないと本来のミッションからずれてしまう。有償支援の営業目標を達成するために色々とセミナーを開催したりしたのですが、結果的に見えてきたのはこのような実情でした。

何よりSaaSだけならまだしも、有償支援サービスは提供することによって人的工数をかなり持っていかれることになるので、事業上はとても大きな影響のある話になります。なのでまだARR10億円を超えない段階では営業目標を持って有償支援を開始するという状態にならなくて良いのではないかと思います。

また、同時にもう1つそれに付随して分かってきたのが「有償支援サービスをフックにSaaSをご提供する」は無理だということです。これは様々な企業にご提案を繰り返してきた結果として、現段階での結論として言えることです。実はSaaSの未利用顧客・既存顧客問わず、様々な企業にご提案をしてきたのですが、結果的に有償支援をすることができたケースは全て、SaaSの導入を検討いただいているor既に活用している会社様でした。つまり、有償支援を受けたいからそのシステムとしてSaaSも導入するという意思決定を引き出すことはできませんでした。

これは、今にして思えば一定当たり前かなと感じているのですが、SaaSの導入はそれ単体でも非常にハードルが高いものです。セキュリティチェックも必要ですし、導入後の活用体制も必要になります。仮に有償支援サービスでそこを手厚くサポートしますというのがあったとしても、SaaSを導入しようと言う意思決定は非常にしづらい。有償支援サービスを購入するのすら、それなりに検討が必要なことなので、そこにSaaSの導入検討を加えてしまうとハードルが高すぎて購買行動がストップしてしまうんですよね。

なので有償支援サービスについては、SaaSの導入を検討していて、しかし活用に不安がある・社員を教育したい、といったニーズがある顧客にご提案・ご提供するということを原則にしています。

3.デリバリに上限をかけないと死ぬ

最後にこちらです。有償支援サービスは人的工数をかなり多く取られることや、通常業務の調整も走る、かつそれが一定長期間に渡って続くため、業務への影響は少なくありません。というか大いに影響します。

であるがゆえに、商品のように扱って多めにご提供してしまうと、理論上のキャパ以内であったとしても社内オペレーションが破綻する可能性があります。なので、提供本数には制限をかけるようにしています。

もう1つ理由があって、それは立ち上げにものすごく時間がかかる、ということなんですね。有償支援は長期間にわたる支援になるので、最初の信頼関係構築や期待値調整がとにかく重要です。そう考えると、プロジェクト初期で関係者と綿密に打ち合わせをして参加メンバーや進行、企業の特性を踏まえた対応、打ち合わせ頻度、レポートライン、アウトプットなどを詰めておくことがプロジェクトの成否を左右する大きな分かれ目になります。

なのでこの立ち上げ期間、およそ1ヶ月程度ですが、この期間はそのあとの5ヶ月よりも2〜3倍の時間がかかる（かけるべき）と想定した方が良いです。そう考えると、この有償支援サービスプロジェクトの開始の時期が被りでもしようものなら一気にチームの状況が火の車と化すわけです。有償支援サービスに手一杯でメンバーが時間を取れないとなると他の支援にも影響が出ますし、それにより有償支援サービスに時間を割けないと、クオリティが低下しそちらでも問題が噴出、延焼する可能性も高くなるのです。

幸いなことに弊社の場合は、最初からそのリスクを察知し、開始時期の制限はかなり慎重にかけていたので問題はなかったのですが、その制約が少しでも緩んでいたらかなり厳しい状況になっていただろうなと思うことが今振り返ってもたくさんあります。

開始時期や同時にデリバリできる本数には自社のキャパを見極めた上で、適切な、ちょっと余裕を持った制限をかけるのがおすすめです。自分が管理できないところで提案が進んでしまうと制御が効かなくなってしまうので、その制限についてカスタマーサクセスのメンバーにはもちろん、セールスメンバーにも周知するのがポイントです。有償支援サービスの提案をするときには、必ず有償支援サービスチームの責任者に相談した上で、と言ったフローも設けていました。これらは本当にやっていてよかったと思うので、ぜひ。

■第3章：有償支援サービス成功の厳選23TIPS

さて最後に第3章では、第2章でご紹介したようなメリットや注意点を踏まえ実際に有償支援サービスを展開していくにあたって、それを成功させる上で大切なTIPSを、サービス立ち上げ全体とデリバリの2パートに分けてご紹介していきます。

サービス立ち上げ全体の7TIPS

★TIPS1：営業→デリバリ(成果創出)→価値定義の順で進めるべし
立ち上げストーリーをなぞればわかりますが、実際に私もこの順で進めています。今振り返っても、今立ち上げの時点に立ち戻るにしても同じ順序で進めるだろうなと思います。一定クライアントニーズがある、と踏んでいるからこそ有償支援サービスが立ち上がろうとしていると思うので、机の上でサービスをこねくり回すよりも、まずはトライアルでも良いのでクライアントにご提供していく中で成果創出を目指し、それができてきた後で改めて価値やターゲットを定めるという順番が後戻りもないし、効率的かつ現実的です。

★TIPS2：資料は必ず定型化する
デリバリ中はこれ、すごく意識しましたね。有償サービスとはいえ、完全にカスタマイズしていたらSaaSに付随しているサービスとしてのクオリティを担保しづらくなっていきます。なので、個別にクライアントに提供する資料をアップデートしたタイミングで、それに合わせてテンプレ資料もアップデートしていくのが超重要です（特に後任のためにも）。

私の場合は、最初から作業する場所に「テンプレ資料」というフォルダを作っておき、作業するたびに「あ、これテンプレ化しなきゃ」っていう意識が働きやすいようにしていました。社内で新しいことを報告するときも「これは既にテンプレ化済みです」「まだですが、来週テンプレ化します」といったことを合わせて報告できるように、ということを徹底していました。

今になって思えば、こうやってテンプレ化していたことは、サービスのスタンダードを作る上で非常に大切な骨格になっていたと思います。個々人が好き勝手にデリバリをしてしまうと統制が取れなくなり管理しづらいし、そうなると何かあった時のリカバリがめちゃくちゃ大変になってしまいます。何より支援が属人化してしまい、サステナブルな発展ができなくなってしまいます。

★TIPS3：コミットラインを定義する
立ち上げで話した「提供価値」を定義するお話と一緒ですが、これをしっかり決めるのはサービスの未来を決める上でとても大切なことなので、それなりにリソースを使って考えて、定めて、周知徹底したほうが良いです。

サービスに関わるのは自分だけではなく、営業する人、デリバリする人、そして実際にサービスを受けるクライアントと多岐に渡ります。こういったメンバー間でサービスのコミットラインの認識がずれていると容易に事故が起こります。クライアントの要望に対して不用意に「できます」と言ってしまったり、デリバリの中で必要以上の稼働が発生してしまったりなど。

なので「コミットするライン」それはつまり「ここにはコミットしない・できない」というラインも含めなのですが、決める必要があります。きちんと定めていてすら都度都度相談というのは発生するものなので、定めておかないと何をか言わんや。言語化して定めることはとても大切です。

★TIPS4：品質担保する責任者の育成を怠らない
有償支援サービスは対価をいただいている以上、通常以上に支援の品質を一定以上に担保する必要があり、そのためにも体制的に品質責任者を置くことがあると思います。将来的にサービスを拡張していくという意味では、この品質責任者の数によってデリバリの本数が制限されてしまうので、サービス拡大を狙うなら早くからこの品質責任者の育成を見越した手を打つ必要があります。

責任者育成のポイントは、立ち上げストーリーでも触れましたが

1. ゴールに向けた長期的計画を立てられるか
2. クライアントをクライアント以上に理解して対話できるか
3. 自社CSに適切にフィードバックできるか

の3点が基本で、かつこれらを育てるのは実践の機会が最適です（人材育成全てに言えることでもありますが）。

なので自分が責任者を持っている案件を部分的に渡していく、自分が見られる範囲で案件を持ってもらうというトレーニングに早期から取り組むべきです。トレーナーによっては視点の転換につまづくことが多いので。

★TIPS5：提供するしないの判断は必ず自チームで
有償支援サービスは一度始めたらそれなりに工数を持っていかれるサービスです。またクライアントにやる気があれば大成功になるとても良いサービスですが、一方でクライアントやサービスに適性がなければ、互いに悲劇が起こりかねないというのも事実です。

その辺の適性は営業だけでは見極められないこともあります。なにせ3ヶ月や6ヶ月を共にするサービスだったりするので、実感を持てと言ってもそれは無理な話だったりする訳で。なので、最終的な提案する・しないの判断は必ず自チームで持つべきです（提案した後に引っ込めるのは互いに失礼なので必ず提案前に相談）。

★TIPS6：1ヶ月に提供できる本数には上限をかけるべし
仮に適性だと思えるクライアントであっても、有償支援サービスの立ち上げは非常に重要な時期で通常の時期以上に工数がかかります（かけるべきです）。なので複数の有償支援サービスの立ち上げの時期が被ると、かなりまずい状況に陥ります。1ヶ月に提供開始できる有償支援サービスの本数は定めた方が良いです。

★TIPS7：有償支援の感覚を通常の支援に持ち込まない
有償支援はクライアントが大成功することが多いのですが、その感覚で通常の支援に入ってみると、うまくいっていない、クライアントのコミットメントを引き出せない、と悩んでしまうことがあります。

しかし有償支援と通常支援ではそもそもサービスに対するスタンスが異なっているので、延長線にあるものではなく別ものと捉えた方が健全だと思っています。もちろん大きく言えば目指すところは一緒ですが、その過程における自分たちの関わり方、カスタマーサクセスのスタンダードもゴールも別にあるとして定義しましょう。

デリバリの16TIPS

★TIPS8：支援のゴールを明確に握る
有償支援サービスは通常より長期間に亘りかつ、通常よりもたくさんの人が関わるので、有償支援サービスで目指す状態、ゴールについては明確に握って言語化しクライアントに確認いただくことが超・超大切（！）です。これがないままに、あるいは擦りあっていない状態でデリバリを始めてしまうと、必ず途中で「思っていたものと違う」「何かが足りない」といった話がクライアントから生まれることになってしまいます。また提供しているメンバーの中でも果たしてこの方向でいいのだろうか、という迷いが結構な頻度で生まれてしまうことになり、支援の方向性もブレてしまうことになります。

支援内容を型化すればするほどやるべきことはテンプレ化できますが、そのサービスでクライアントが達成したいことは必ず個々に異なるはずなので、それをきちんと言語化しましょう。これはプロジェクトの超初期フェーズに実施すべきことなので、支援が始まるタイミングでは必ず「支援のゴールが明確か」を意識しましょう。

★TIPS9：立ち上げ時の工数の貼り方を間違えない
ここまでに何度も書いていますが、有償支援サービスはクライアントと長く並走するサービスになるので、メンバーとクライアント間で信頼関係を構築できるかどうかがそのあとの支援に大きく関わります。また後述しますが、クライアントメンバーは固定の方が良いため、一度クライアントからの信頼を失ってしまうと信頼回復に多大に工数を持っていかれることになり、支援どころではなくなってしまいます（信頼もそうですが、安心感というのも人と仕事する上では大切なポイントになります）。

それがゆえに立ち上げ時は通常以上に工数がかかるし、かけるべきです。ざっくり言っても以下のようなことは立ち上げ時に把握する必要があります。

・クライアントのサイトやデータの状況
・クライアントビジネスモデルとゴール
・クライアントの組織事情（過去から未来）
・個人個人の思考行動の癖
・UX企画定着/成果創出のためのハードル

一度把握できてしまえばスムーズに気持ちよく仕事ができますが、それを掴むためには何度かコミュニケーションを繰り返していく必要があります。それにあたってクライアントのヒアリング、ゴール設計、スケジュール立てなどを仕事の基本(レスポンス・ゴール/アジェンダ設計・ドキュメンテーションなど)をぬかりなく推進するのはなかなかに工数がかかるので、その前提でサービスを設計するようにしましょう。

★TIPS10：有償支援サービス自体は最初から提供するのがベスト（途中切り替えは無理）
通常のカスタマーサクセスを提供している場合の話ですが、クライアントに「一旦通常のカスタマーサクセスで初めて、その後もう少し支援をしてほしいと思ったら、途中から有償支援に切り替えることができますか」と聞かれることがあるのですが、明確にオススメしないようにしています。

理由は簡単で、有償支援サービスで目指しているゴールは、大抵の場合通常のカスタマーサクセスで目指すゴールと異なるからです。仮に実施していること自体は似ているように見えても、ゴールが異なっていれば、細かいフォローの仕方やアジェンダ設計も異なってきます。なので、もし仮に切り替えたとしても結局は最初からやり直しになることが多いと認識しています。

最初からやり直すのであれば、スタートの時点でどちらにするかをきちんと決めて臨んだ方が、お互いにロスが少なくて済みます。なので最初から何を提供するかをきちんと握って合意してから進めていくのがポイントです。

★TIPS11：クラインアント側の参加メンバーは固定せよ
クライアント側の参加メンバーは固定した方がいいです。これも質問で「前半の3ヶ月と後半の3ヶ月で参加するメンバーを入れ替えてもいいですか？」というものをよくいただくのですが、これも明確にNoとお答えしています。

誤解のないようにですが、参加したり巻き込まれるメンバーが増えていくこと自体はウェルカムで、我々としても推奨しています。利用者が増えれば増えるほど相乗効果が生まれるのがSaaSなので。ただし、コアとなるメンバーは変えてはいけないです。有償支援サービスで対象となる方は、その後社内でそのSaaSを活用するにあたってのエヴァンジェリストになっていただく可能性が非常に高い（後述します）ので、この方の利用スキルがどれだけ上がるかが、その企業における全体スキルの伸び代を定めることになります。

もしコアメンバーが途中で変わってしまうと、そこまで教えてきたことがゼロリセットになってしまい成長が促進されません。弊社のプログラムの場合は後半で社内メンバーを巻き込むことまで含めてプログラムの一環だったりするので、途中で止めるのと最後まで実施するのとだと、スキルの伸びが全く異なります。フェーズが進むにつれて巻き込むメンバーが増えるのは良いのですが、途中で変更するのは組織全体としての活用支援の観点でもオススメできません。

★TIPS12：クライアント側の参加者はその後社内のエバンジェリストになる前提で選定いただく
SaaSの活用という観点で6ヶ月間並走すると活用のスキルはかなり高まりますし、結果として獲得したいスキルや成果、定着の基盤もかなりその方々を中心に構築されることになります。なので、その後のその企業におけるSaaSの活用の中心はその方々に担って頂くことが圧倒的に多いです。

そのために、最初にメンバーを選定いただくときも、その観点、つまりその後企業にSaaSの活用を普及していくという観点で適切な人を選ぶのがポイントです。チーム内で巻き込み力がある人や、複数部署にまたがるなら、それぞれの部署に持ち帰って研修などができそうな人を選ぶのが良いです。

★TIPS13：参加できない人がいた時は、クリティカルであれば補講する
長期間サービスを提供していると、当然とある回に急病や出張で参加できない人がいるというケースも出てきます。もちろん前提としてそういったことが起こらないように事前察知、リスケは柔軟に対応するという前提ですがそういったことが起こってしまうのはある程度は避けられないもの。

そういう場合どう対応するかですが、資料や議事録を共有というのは当然やるとは思うのですが、その回の重要性に応じて、必要であれば補講を行うのがおすすめです。普段チームメンバーと一緒にやっているからこそ、そういった1対1の補講の場は一人ではなかなか聞けなかったことが出てきたり、活用で困っていることがより深く聞けたりするチャンスになったりします。

こちらとしては工数が多少かかりますが、もともと準備をしていることがほとんどだと思うので、追加でかかるとしても3〜5時間程度です。その程度で個人の悩みが解消されると考えると、リスク/リターンではリターンの方が大きいので、こういう時は補講という形で追加の回を設けています。（補講することを明言・確約すると本回への参加コミットが薄まる＋補講実施の判断は最後は自分たちで決められるようにしておいた方がいいので、明言や確約はやらない方がいいですが、その上でやる分にはおすすめです。）

★TIPS14：先方社内に協力者を作り事務局を立ち上げる
長期間の支援でかつクライアント内でSaaSの利用を活性化し成果を生んでいくという支援になるので、先方の中に協力者がいないと無理です。支援を進めていくと、他部署への協力が必要だったり、宿題の取りまとめなどをお願いしなければならないことが出てきます。そういったときにクライアント社内に協力してくれる人がいないと成り立ちません。

弊社の場合は事務局と称して、プロジェクトオーナーである上長、推進者という名称で、社内の取りまとめや実質的な連絡窓口になってくださる方、そして我々から成り立つメンバーで月に1回は事務局ミーティングを行うようにしていきます。参加メンバー全員と深い関係を担保していくのは最初は難しいのですが、人数を絞り共同パートナー的な位置付けで、クライアントと事務局を立ち上げることで、深く社内の事情を把握することができたりします。なので、推進のコアとして事務局を立ち上げるのが非常に重要です。

★TIPS15：メンバーの変化状況を上長に伝える
事務局ミーティングですが、プロジェクトの進行状況を伝えるのは当然なのですが、実際にオーナーである上長が興味があるのは、誰がどれくらいのスキルに達しているかです。なのでこのメンバーの変化状況については、逐一お伝えすることが大事です。

また伝える時は定量的なSaaSの活用度合いだけでなく、トレーナーの立場から見た第三者的な定性的な意見をお伝えすることが得てして喜ばれます。大抵のクライアントではこういったサービスを、自社スキルに課題感があるから購入しているわけなので他社と比べてどの程度のスキルに達しているのか、という点については非常に気になるポイントだと思います。

なので忖度不要で、現状と今後の伸び代、そのために必要な指導などを率直に話すことで良い場になります。

★TIPS16：打ち合わせ頻度は2週に1回がベスト
これは色々と議論があって、週1がいいんじゃないか、月1でもいいんじゃないかという話が最初はありました。ちなみに元々の方法論では打ち合わせは月1回と定義されていたのですが、やってみたところ、週に2回が最適でした。

月1だと以前習ったことをもう思い出せない、遠い記憶の彼方になっているということが頻発するので、学習効率が落ちます。一方で週1にしてしまうと、前回ならったことを実践する時間がなく「すみません、まだ出来てません」ということが多発してしまいます。なので、記憶の維持と実践の担保という2つの観点から隔週に1回が最もバランスが取れていると感じています。

ちなみに打ち合わせは隔週ですが宿題の進捗確認などは間にあっても全然いいですし、宿題の提出タイミングを早めのところに設計する、というのも実践の促進という観点で意味がありました。

★TIPS17：最初期のスキルで伸び代を決めつけない
これはクライアント側の参加メンバーのスキルの話なのですが、プロジェクトスタート時点でのスキルと、そのあとにどれくらいのスキルまで伸びるかというところは、経験則的にいうと全くの無関係です。というか大体の場合、支援を半年間行ってみると「最初はこの人がこんなに伸びるとは思わなかった！」ということが圧倒的に多いです。

なので最初期のメンバーの状態ややる気だけで判断せずに、根気よく支援に取り組み、1人1人と丁寧に向き合っていくことが非常に大切です。

★TIPS18：やる気のない人を立ち上げるよりやる気のある人が超成果出すことにコミットすべし
支援を進めていくと、やる気がないなどの問題（前向きでないなど）からなかなかうまくいかない人と、積極的に取り組んでうまくいきかけている人に分かれるということがあります。そういうときにポイントなのは、うまくいかない人を必死で支援することではなく、うまくいきかけている人に支援のフォーカスを当てて、その人が大成功する状態をいかに早く作れるかということです。

やる気のない人を放置するということではありません。というのもやる気のない人が変わるきっかけは、ほとんどの場合、社外の人間からの言葉ではなく、隣に座っている同僚の成功がきっかけになるのです。なのでもうちょっとで成果が出そうな人をまずは支援して成功事例を作りに行く。そうするとやる気のない人も重い腰をあげることが多いです。

クイックウィンとよく言いますが、人やもっというと部署や組織視点でも一緒で、やる気がない人・動かない人を動かすよりも、動く気がある人を後押しした方が最終的な変化の総量は大きくなるのです。

★TIPS19：クライアントからの率直なFBを収集する
事務局ミーティングでもいいですし、1回1回のお打ち合わせ後のアンケートでも良いので、個別の支援に対するフィードバックは積極的に収集すべきです。クライアントが組織文化的に支援内容に違和感を感じているケースもありますし、個人レベルでちょっとついていけない、あるいはもっとアドバンスなことをやりたいというニーズが隠れているケースもあります。

そういったニーズは早めに察知して手を打たないと、放っておくと違和感が広がっていくばかりなので、クライアントからのフィードバックは率直に集めましょう。

★TIPS20：モチベーション設計を必ずせよ
支援が6ヶ月と長引くので、途中やる気が下がってだれてしまうことがあります。なので、支援のポイントポイントでモチベーションが高まるような設計をすることが重要です。

弊社の場合は、2ヶ月に1回、SaaSの活用を3つの観点からアワード的な賞を作り、上長の前で該当する人を表彰するということをやっています。この表彰はあらかじめ行いますよと伝達してあるので、賞を取れるようにと頑張っていただけますし、毎回リセットするので、一度取れなくても次はという風に感じていただけています。

これに限らずですが、モチベーションが続くような要素を入れるのはポイントです。コツコツと達成感がある、褒めてもらえる、などがキーワードになると思います。

★TIPS21：支援内容はいろいろと試す
立ち上げストーリーや有償支援サービスのメリットの章でも語りましたが、有償支援サービスは一の中身は定テンプレ化されているといっても、次々に顧客の中でも新しい課題が生まれてくるものです。なのでその新しい課題に向き合った時はカスタマーサクセス全体のレベルアップのチャンスと捉えて、臆さず新しい支援方法をチャレンジしてみるべきです。

どんな新しい支援も、まずは特定の1社にとって意味があるものでない限り型化する意味はありません。また有償支援サービスで提供している顧客は往往にしてサービスの利用度が高まっているので、そんな時に浮上するクライアントの課題は、そのSaaS全体の問題に通ずるものがあることが非常に多いです。

目の前に向き合っている顧客の課題を解決するために、支援を提案し検討しデリバリしてみると、様々な発見があるし、そういったことができるのはある意味でこういうった有償支援の場がもっとも適しているので、積極的に挑戦していきましょう。

★TIPS22：将来的に型化できない支援はやらない
と言いつつですが、明らかに型化が不可能な支援はやらない方が良いです。例えばSaaSで目指す事業の理想状態から全く離れてしまうようなサービスであったり、特殊なスキル、あるいは会社の事情に依存する支援ですね。自分たちでいうと「レポートを代理する」など。

そういったものは型化できる見込みは薄いわけですし、そもそも有償支援サービスとして立ち上げる意味もないので、手をつけない方が良いかと思います。

★TIPS23：6ヶ月先と遠くても常にゴールとその先を意識すべし
有償支援サービスのゴールは弊社の場合は6ヶ月後の時点に設定されているのでかなり長期的です。であるがゆえに、ついつい最終的なゴールを忘れて目の前の支援やクライアントの課題に左右されて支援を決めてしまいがちです。ただしそういったことが続くと結果的に顧客満足度は高まったけどゴールは達成されていない、ということが起こりかねません。

特に責任者に求められることですが、目の前の顧客の課題にばかり左右されすぎず、6ヶ月後に達成したいゴールにきちんと向かっているのか、そこに向けて足りないものは何か、と自問自答し続けることがポイントです。もっというとSaaSである以上、プロダクトの活用はずっと続くわけなので、有償支援サービスが終わった後にきちんとクライアントが自走できる状態に向かっているか、それに向けて足りないことはないのか、という観点を自らに厳しく問い続ける必要があります。そしてそれに向けた計画をたて、必要な布石を今のうちからあらかじめ打ち続けることが極めて重要になってきます。

最後に

長くなってしまいましたが、有償支援サービス立ち上げの記録は以上となります。今はこの有償支援サービス自体は後任の方に託し、私自身は離れているのですが、立ち上げたこと自体はとても良い経験だったし思い入れも深いので、このような形でまとめられて良かったです。

結局書いてみて、サービスのディティールや失敗談などはここに書ききれないこともたくさんあったので、もし他にも聞いてみたいということがあれば、ぜひご質問くださいませ。Twitterもやっております。

タイトル未設定

それでは！