CSプレイブックの作り方｜再現性ある対応設計と実践

カスタマーサクセス（CS）の担当者が2〜3人に増えた途端、オンボーディングの説明順も、更新提案を切り出すタイミングも人によって変わり、成果がばらつき始めた。こうした状態に心当たりがあるなら、CSプレイブックの整備を始める時期です。なお本記事の「CS」はカスタマーサクセス、つまり顧客が製品で成果を出し続けられるよう支援する活動を指します。プレイブックは担当者が少人数のうちから作るほど、後の増員や対応範囲の拡大が楽になります。この記事では、プレイブックに何を書き、どの順で作り、どうやって日々の運用に載せ続けるかを、テンプレートとつまずき所込みで解説します。CS組織全体の立ち上げ手順はCS組織の立ち上げ方で解説しています。本記事はそのうち、業務の型化＝プレイブック作成だけを掘り下げます。

CSプレイブックとは何か

CSプレイブックとは、オンボーディングの手順、活用支援を始めるトリガー、更新提案のタイミングといった一連の顧客対応を、誰がやっても一定の質で回せるように標準化した手順書です。単なる操作マニュアルでもなければ、営業のトークスクリプトでもありません。「どの顧客に・いつ・何をするか」という判断と行動をひとつながりで定義する点に本質があります。作る目的は対応品質の属人化を止めることにあり、それはデータの一元化とプロセスの標準化という2つの軸で成り立ちます。ここから先の章では、この標準化を具体的にどう書き起こすかを掘り下げます。

属人化というと「情報が個人やExcelに散らばっている状態」を思い浮かべがちですが、CSの現場ではもう一方の軸、つまり「対応プロセスが標準化されていない状態」のほうが成果のばらつきに直結します。ベテランCSM（カスタマーサクセスマネージャー：顧客の成果創出を伴走する担当者）が感覚でやっている判断を、誰でも再現できる形に言語化するのがプレイブックの役割です。

プレイブックとマニュアル・ナレッジの違い

この3つは抽象度が異なります。マニュアルは「製品のこのボタンを押すと設定が保存される」といった操作手順で、最も具体的な層です。ナレッジは過去の問い合わせ対応や個別事例の蓄積で、検索して参照する情報の集まりです。プレイブックはその中間で、「オンボーディング初期の顧客には、キックオフから7日以内に初期設定を完了させ、14日以内に初回の成功体験まで到達させる」といった、局面ごとの標準的な進め方を定義します。

言い換えると、マニュアルは「操作の仕方」、ナレッジは「過去の答え」、プレイブックは「進め方の型」です。この3つを混同して1つのドキュメントに詰め込むと、更新もされず参照もされない資料になります。役割を分けて管理するのが前提です。

なぜ少人数のうちに作るのか

CSが1〜2人のときは、頭の中に対応の型が入っているため、プレイブックがなくても回ります。問題は増員したときに起きます。新しく入った担当者は、既存メンバーの対応を見よう見まねで覚えるしかなく、そのたびに解釈のずれが生まれます。オンボーディングの説明順、活用支援に動くタイミング、更新提案の切り出し方が人によって変わり、同じ料金を払っている顧客の体験にばらつきが出ます。

型がない状態で人数が増えるほど、後から標準化する対象、つまりそれぞれの担当者が独自に確立したやり方が増え、統一が難しくなります。少人数のうちに、成果の出ている対応を型として固定しておけば、増員のたびにプレイブックへ合流させるだけで済みます。プレイブックを早く作るほど後が楽になるのは、標準化すべき「我流」が少ないうちに基準を敷けるからです。増員や役割の割り当てを計画する段階では、CSの体制・役割設計とあわせて進めると、型化と体制がかみ合います。

CSプレイブックに書く項目

プレイブックに最低限そろえる型は、顧客のライフサイクル（オンボーディング→活用・定着→更新・拡大）に沿って、各局面の「対象・トリガー・標準アクション・使う資料・完了条件・引き継ぎ先」を定義することです。ただし全局面を最初から作り込む必要はありません。解約の多くはオンボーディング期に初回の成功体験まで到達できなかった顧客で起きるため、まずオンボーディングのプレイブックから着手するのが現実的です。以下では、共通で入れる項目と、局面ごとの型を順に具体化します。

プレイブック1枚に共通で入れる6項目

局面が違っても、1枚のプレイブックに共通で入れる項目は次の6つです。

• 対象顧客 このプレイブックが発動する顧客の条件（例：契約後30日以内のすべての新規顧客、年間契約額◯円以上の顧客など）。
• トリガー 対応を開始する引き金となる出来事や状態（例：契約締結、主要機能の30日未使用、更新期日の90日前）。
• 標準アクション トリガー発生時に実行する対応の中身と順序。
• 使う資料・テンプレート そのアクションで使うキックオフ資料、設定ガイド、メール文面など。
• 完了条件（成功の定義） このプレイブックが完了したと判断する状態（例：初回の成功体験に到達、更新契約の締結）。
• 引き継ぎ先 完了後に対応を渡す相手（次の局面の担当者、営業、サポートなど）。

この6項目がそろっていれば、担当者が変わっても「今この顧客に何をすべきか」を同じ基準で判断できます。特に抜けやすいのがトリガーと完了条件で、この2つが曖昧だと後述するつまずき所に直結します。

オンボーディングの標準手順

オンボーディングは、キックオフ→初期設定→初回の成功体験までを日数の目安と完了条件つきで定義します。たとえば「キックオフミーティングは契約締結から3営業日以内」「初期設定の完了は7日以内」「主要機能を使った初回の成功体験は14日以内」といった具合に、各段階に期日と状態を紐づけます。

初回の成功体験（顧客が製品を使って最初に価値を実感する瞬間）を完了条件に据えるのがポイントです。「ログインした」「設定が終わった」で完了にすると、使い始めたが成果につながらない顧客を取りこぼします。完了条件は「顧客が達成したい業務上の成果を、製品で1回体験した状態」まで踏み込んで定義します。この状態に期日内で到達しなかった顧客は、次の活用支援の対象として自動的に引き継がれるように設計します。

活用支援を始めるトリガーと対応

活用・定着の局面では、放っておくと解約に向かう顧客を早めに検知するためのトリガーを定義します。代表的なのは、ログイン頻度の低下、契約時に想定していた主要機能の未使用、ヘルススコアの低下です。ヘルススコアとは、利用状況や問い合わせ状況などを組み合わせて顧客の健全度を示す複合指標で、何を要素にどう重みづけするかは各社が自社の解約要因をもとに定義します。汎用の正解値はありません。

トリガーを検知したら、原因の切り分けから入ります。たとえば「主要機能を30日間使っていない」なら、設定でつまずいているのか、社内での利用が広がっていないのか、そもそも別の使い方をしているのかで打ち手が変わります。プレイブックには「30日未使用を検知したら、まず利用状況を確認し、設定不備なら再オンボーディングの案内、利用範囲が狭いなら活用事例の共有」といった分岐まで書いておくと、担当者ごとの判断のばらつきが減ります。

更新・アップセル提案の型

更新・拡大の局面では、更新の何か月前から動き出すかを固定します。年間契約なら、更新期日の90日前を着手のトリガーにするのが一般的です。この時点で利用状況とヘルススコアを確認し、順調なら更新に加えてアップセル（上位プランや追加機能の提案）やクロスセルの余地を探り、不安があれば更新確度を上げるための対応を先に打ちます。

アップセルの判断材料は「顧客が現在のプランの上限に近づいているか」「新たな業務課題が生まれているか」を軸にします。ここで重要なのが営業への引き継ぎラインの定義です。金額の大きい拡大提案や新規部門への横展開は営業が担うケースも多く、「どの規模・どの内容の提案からCSではなく営業に渡すか」をあらかじめ線引きしておかないと、CSと営業のどちらも動かない空白が生まれます。

CSプレイブックの作り方（作成手順）

プレイブックは、ゼロから理想の手順を書き出すのではなく、すでに成果の出ている自社の対応を分解して型にするのが最短です。理想から書くと現場感のない絵に描いた餅になり、誰も使いません。作成順は「①成果の出た対応を1〜2件棚卸し→②局面ごとに分解→③トリガーと完了条件を言語化→④テンプレ・資料を紐づけ→⑤1顧客で試す→⑥修正して横展開」の6ステップです。各ステップのアウトプットまで含めて具体化します。

ステップ1：成果の出た対応を棚卸しする

最初にやるのは、直近で更新・定着・アップセルに成功した顧客を1〜2件選び、その対応を担当者から聞き取ることです。誰の・どの顧客を素材にするかが質を左右します。選ぶべきは「特別に優秀な担当者が例外的な工数をかけた案件」ではなく、「標準的な体制で無理なく成果が出た案件」です。再現できない対応を型にしても、他の担当者が実行できません。

聞き取りでは「いつ・何をきっかけに・何をして・どうなったか」を時系列で書き出します。この段階では整えず、事実をそのまま並べます。アウトプットは、成功した対応の生の時系列メモです。

ステップ2：ライフサイクルの局面ごとに分解する

棚卸ししたメモを、オンボーディング／活用・定着／更新・拡大の局面に切り分けます。1件の成功事例の中に複数の局面が混ざっているので、「これはオンボーディングの動き」「これは活用支援の動き」と仕分けます。局面ごとに分けることで、後から他の顧客に横展開しやすくなり、更新もしやすくなります。

アウトプットは、局面ごとに整理された対応の一覧です。ここで局面をまたぐ引き継ぎ（オンボーディング完了後に誰が活用支援を担うか）が見えてきます。

ステップ3：トリガーと完了条件を数値・条件で言語化する

分解した対応を、発動条件（トリガー）と終了条件（完了条件）で挟みます。ここが作成の山場です。棚卸しのメモには「なんとなく元気がなさそうだったので連絡した」といった主観的な記述が多く残ります。これを「直近30日のログインがゼロ」「主要機能Aの利用が2週間停止」のように、誰が見ても同じ判断ができる数値やイベントに落とし込みます。

完了条件も同様に、「顧客が納得してくれた」ではなく「初回の成功体験に到達」「更新契約を締結」と観測可能な状態で定義します。アウトプットは、各アクションにトリガーと完了条件が付いた対応表です。この言語化ができるかどうかで、プレイブックが運用に載るか死蔵するかが分かれます。

ステップ4：資料・テンプレート・メール文面を各アクションに紐づける

トリガーと完了条件が決まったら、各アクションで実際に使う資料を紐づけます。キックオフ用のスライド、初期設定のチェックリスト、活用支援で送るメールの文面、更新提案の資料などです。担当者がプレイブックを開いたときに、「次に何をするか」だけでなく「そのとき使うもの」までワンセットで手に入る状態にします。

ここで資料が存在しないアクションが見つかることがよくあります。その場合は、成果の出た担当者が実際に使っていたものを回収するか、新たに用意します。アウトプットは、資料へのリンクが埋まった実行可能なプレイブックです。

ステップ5：1顧客で試し、修正して横展開する

いきなり全顧客に適用せず、まず1顧客で試します。実際に運用してみると、トリガーが早すぎる・遅すぎる、完了条件が現場の実感と合わない、想定していない分岐が出てくる、といったずれが必ず見つかります。1顧客で回して修正し、無理なく機能することを確認してから他の顧客・他の担当者へ広げます。

横展開の際は、他の担当者に「この通りにやってみて、合わないところをフィードバックしてほしい」と渡します。現場からの修正を吸い上げる前提で広げることで、押しつけの型ではなく全員が使う型になります。

作成でつまずきやすい点と回避策

多くのCSプレイブックが機能しないのは、能力や熱意の問題ではなく、決まった箇所でつまずくためです。典型的なのは、内容が抽象的すぎて判断に使えないか、逆に作り込みすぎて誰も更新しなくなるかの両極端です。ここでは現場で繰り返し起きる4つの失敗と、それぞれの回避策を具体的に示します。用語解説にとどまる上位記事では扱われない、作成後に効いてくる観点です。

トリガーが「様子を見て」で止まっている

最も多いのが、トリガーが主観のままになっている失敗です。「利用が落ちてきたら連絡する」「様子を見て提案する」と書かれていても、「落ちてきた」の基準が人によって違えば、結局は担当者の勘に戻ります。これはプレイブックを作った意味を失わせます。

回避策は、トリガーを必ず数値かイベントに落とすことです。「利用が落ちてきたら」は「直近30日のログイン回数が前月比で半減、またはゼロ」に、「様子を見て」は「更新期日の90日前」に置き換えます。数値で決められない要素が残る場合も、「ログイン低下を検知したら、まず◯◯を確認する」と、次の観測ステップだけは固定します。

完了条件がなく、いつまでも案件が閉じない

完了条件（成功の定義）を書かないと、対応がいつ終わったのか誰も判断できません。オンボーディングがだらだら続き、活用支援に移るべき顧客がオンボーディング扱いのまま放置される、といった状態が起きます。担当者は「まだ終わっていない気がする」対応を抱え続け、対応の総量が把握できなくなります。

回避策は、各局面に観測可能な完了条件を1つ決めることです。オンボーディングなら「初回の成功体験への到達」、更新なら「更新契約の締結」です。完了条件を満たしたら次の局面へ引き継ぐ、という運用をセットにすれば、対応が滞留しません。

作ったが日々の運用に載らない

丁寧なプレイブックを作っても、それがドキュメントの中だけに存在し、日々の顧客対応と切り離されていると使われなくなります。担当者は毎日SFA/CRMや顧客リストを見て動いているのに、プレイブックは別の場所にある資料のままだと、いちいち開かれず、やがて存在を忘れられます。

回避策は、プレイブックのトリガーを、担当者が日常的に見る画面の中で発火させることです。詳しくは次章で扱いますが、「30日未ログイン」というトリガーを頭で覚えておくのではなく、その条件を満たした顧客が自動でタスクや通知として担当者の手元に上がってくる状態を作ります。プレイブックを運用ツールに接続する設計まで含めて、はじめて型が回ります。

作り込みすぎて更新されない

最後の失敗は、逆方向です。全局面・全パターンを網羅した分厚いプレイブックを最初から作ろうとすると、完成する前に力尽きるか、完成しても現場の変化に追いつけず更新されなくなります。使われないうえに更新もされない資料は、間違った古い手順を広める害さえあります。

回避策は、最初はオンボーディングのプレイブック1枚だけに絞ることです。解約はオンボーディング期に集中しやすいため、投資対効果も最も高くなります。1枚が回り始めてから、活用支援、更新提案へと局面を1つずつ足していきます。プレイブックは一度に完成させる文書ではなく、局面ごとに育てる仕組みだと捉えると、更新が続きます。

作ったプレイブックを運用し続ける仕組み

プレイブックは作って終わりではなく、トリガーの検知と対応漏れの防止を日々の運用に組み込めるかで成否が決まります。「30日未ログイン」や「更新期日の90日前」といったトリガーを人が目視で追う運用は、顧客数が数十社を超えたあたりで破綻します。ここでは、トリガーを検知して担当者に対応を促す仕組みと、四半期ごとにプレイブックを点検する運用監査の観点を示します。

トリガー検知と対応漏れの防止

トリガーの検知は、SFA/CRM（SFA＝営業支援システム、CRM＝顧客関係管理。どちらも顧客情報を一元管理する仕組みであると同時に、案件を前に進める・顧客との関係を長期に築くという業務の考え方でもあります）に載せて自動化するのが現実的です。顧客の利用状況や更新期日をシステム側で監視し、プレイブックで定義したトリガー条件を満たした顧客を、担当者のタスクや通知として自動的に上げる形にします。これにより、担当者は「どの顧客に今何をすべきか」を目視で探す必要がなくなります。

例えばMazrica SalesのようなSFA/CRMでは、顧客行動やデータ更新をトリガーに、通知・メール送信・データ更新などを自動実行するCRMオートメーションがあり（実行上限はStarter 3回/月・Growth 10回/月・Unlimited 無制限）、プレイブックで定義したトリガーを運用に載せられます。対応漏れの可視化という点では、案件ボードで直近のアクション状況を色分けする機能（青＝1週間以内にアクション／黄＝1か月以内／赤＝1か月以上アクションなし）を、放置されている顧客を一目で見つける手段の一例として使えます。また、AIアシスタントが顧客との活動履歴を要約して要点・課題・次のアクションを提示する機能は、活用支援のトリガー検知を補助する使い方が考えられます（要約や提案はAIが生成するため、内容は担当者が確認して判断します）。こうした自動化や可視化の機能は他のSFA/CRMにも同種のものがあり、自社の運用に合うものを選ぶ観点で見るとよいでしょう。

対応の濃さによってプレイブックを分けたい場合、たとえば手厚く伴走するハイタッチと、システム主導で効率的に支援するテックタッチとで運用の仕組みは変わります。この分け方はハイタッチ・テックタッチの設計で詳しく扱っています。

プレイブックを見直す運用監査

トリガーを自動化しても、トリガーそのものが現実に合わなくなれば型は劣化します。そこで四半期に1回、プレイブックを点検する時間を設けます。点検する観点は主に3つです。1つ目はトリガーの発火率で、ほとんど発火しないトリガーは条件が厳しすぎ、逆に発火しすぎるトリガーは対応が追いつかず形骸化します。2つ目は完了条件の妥当性で、完了としているのに解約や不満が続く場合、完了条件が甘い可能性があります。3つ目は成果指標との相関で、プレイブックどおりに対応した顧客の定着率・更新率が、そうでない顧客より実際に高いかを確認します。

相関が見られないプレイブックは、アクションの中身かトリガーのどちらかがずれています。どの指標で成果やトリガーを測るかの設計はCSのKPI・目標設定で扱っています。四半期ごとの点検を通じて、プレイブックは作った時点の仮説から、成果に裏づけられた型へと更新されていきます。

まとめ

CSプレイブックは、成果の出ている自社の対応を分解して型にし、トリガーと完了条件を数値で言語化して、日々の運用に載せることで機能します。理想から書き起こしたり、全局面を一度に作り込んだりすると、使われずに死蔵します。

目的によって最初に着手する場所を変えるのが現実的です。解約抑止が主目的なら、まずオンボーディングのプレイブック1枚を、完了条件を「初回の成功体験まで」で定義して作ります。アップセルが主目的なら、更新提案の型と、営業への引き継ぎラインの言語化を先に進めます。いずれの場合も、最初の一歩は小さくして構いません。直近で更新・定着に成功した顧客を1件選び、その対応を局面ごとに書き出すところから始めれば、それがそのままステップ1の素材になります。

体系的な全体像はCS組織の立ち上げ方で解説しています。役割分担や増員の計画とあわせて、業務の型化を進めてください。

よくある質問

Q CSプレイブックとオンボーディングのマニュアルは何が違いますか

A

マニュアルは製品の操作手順を示すもので、「この画面でこう設定する」という具体的な作業を説明します。オンボーディングのプレイブックは、「契約から何日以内にキックオフし、いつまでに初回の成功体験へ到達させ、到達しなければ次に何をするか」という進め方の型を定義します。マニュアルが「操作の仕方」を答えるのに対し、プレイブックは「誰に・いつ・何を・どこまでやるか」の判断と行動を標準化します。実務ではプレイブックの中から具体的な操作マニュアルへリンクを張り、両者を役割分担させる形が扱いやすいです。

Q プレイブックは何ページくらい、どこまで細かく書けばよいですか

A

ページ数より、トリガーと完了条件が観測可能な形で書かれているかが重要です。目安としては、1つの局面につきプレイブック1枚（対象顧客・トリガー・標準アクション・使う資料・完了条件・引き継ぎ先の6項目が埋まった状態）で始めれば十分です。細かく書きすぎると更新されなくなるため、最初はオンボーディングの1枚に絞り、運用しながら分岐や例外を足していくのが続けやすい粒度です。判断が担当者の勘に戻らない程度に具体的であれば、それ以上の作り込みは後回しにして構いません。

Q カスタマーサクセスが1人でもプレイブックは必要ですか

A

増員の予定があるなら、1人のうちから作る価値があります。1人で回しているときは頭の中に型があるため不便を感じませんが、その型が言語化されていないと、2人目が入った瞬間に対応品質のばらつきが始まります。むしろ1人のうちのほうが、自分の成功対応を素材に短時間で型化でき、標準化すべき「我流」が少ない分だけ作りやすいです。当面増員がなく、自分の対応に迷いもないのであれば、優先度は下げて構いません。増員に向けた採用や育成の進め方は採用・人員計画の立て方も参考になります。

Q プレイブックはExcelやドキュメントとSFA/CRMのどちらで管理すべきですか

A

設計と実行を分けて考えると整理できます。プレイブックの内容そのもの（局面ごとの対応の型やテンプレート）は、ExcelやドキュメントなどSFA/CRM以外で持っても問題ありません。ただしトリガーの検知と対応の実行は、担当者が日常的に見るSFA/CRM側に載せないと運用に定着しません。「30日未ログイン」を人が目視で追う運用は顧客数が増えると破綻するため、条件を満たした顧客が自動でタスクや通知に上がる仕組みは、SFA/CRM上に置くのが現実的です。

Q 作ったプレイブックが使われなくなるのを防ぐにはどうすればよいですか

A

使われなくなる原因はたいてい2つで、日々の運用画面と切り離されていることと、内容が現実に合わなくなっても更新されないことです。前者は、トリガー条件を満たした顧客が担当者のタスクや通知に自動で上がるようにして、プレイブックを別資料として開かなくても対応が始まる状態を作ることで防げます。後者は、四半期に1回、トリガーの発火率・完了条件の妥当性・成果指標との相関を点検する時間を運用に組み込むことで防げます。作りっぱなしにせず、点検と更新をカレンダーに固定するのが最も効きます。