営業からCSへ何を引き継ぐ？8項目の実務テンプレート

顧客が期待する変化と根拠、契約・実装範囲、営業が伝えた条件、両者のずれ、解消方法と責任者・期限、顧客確認、CS・実装担当の受入状態を共有します。受け手が期待・提供範囲・未解決・停止条件を自分の言葉で再説明し、渡し手が訂正した後に受領を確定します。開始承認は別の判断です。

契約後に選択理由が書き換わる可能性と用語の限界は「認知的不協和」が扱います。ここでは顧客の心理を推測せず、期待・合意・提供範囲を記録で照合する手順に絞ります。

営業・CSの引き継ぎは、資料の移動ではなく期待と範囲の照合

まず、次の八項目を一枚へ置きます。法定様式や検証済み尺度ではないため、取引、業界、リスク、社内規程に応じて必要項目と承認者を追加します。

1. 顧客が期待した変化
2. 話者・日時・証拠・意思決定への影響
3. 契約・注文書等で確認した合意範囲
4. 実装できる機能・対象・条件・対象外
5. 営業が説明した内容と留保条件
6. 一致・要確認・不一致の判定
7. 解消方法・責任者・期限・顧客確認
8. CS・プロダクト・実装担当の受領、理解確認と開始承認

たとえるなら、営業・CSの引き継ぎはリレーのバトン渡しに近いものです。資料というバトンを手渡すだけでなく、どの区間を誰が走り、受け取った人が開始できる状態かまで確かめます。ただし実際の契約では、顧客が期待を訂正でき、契約文書・見積・承認済み仕様が優先されます。速く渡すことだけを成功にしません。

前話「負けた商談の勝ち方」では、ミナトが大型失注、小規模範囲の発注先決定、将来の相談意向を分けて記録した。北辰を出た直後、CSマネージャーの瀬戸から「契約後の案件会議に参加してほしい。営業側の記録も一緒に確認したい」と連絡が届いた。

リードクラフトのガラス会議室。モニターには、星丘学習サービスの契約後案件が映っていた。城南校で先行導入する範囲は契約記録にある。担当者、開始候補日、対象機能も書かれていた。

瀬戸が止めたのは、営業の商談メモにあった一文だった。

ミナトは最終デモの記録を開いた。自分が伝えたのは「担当講師が同じ画面で引き継げます」という説明だった。顧客側の議事録には、「保護者が前回の相談を説明し直さず、担当講師が授業前に注意点を確認できる状態」と残っていた。

同じ「引き継ぎ」という言葉でも、指しているものは違った。

記録	その記録が確認できること	その記録だけでは決められないこと
顧客の発言・議事録	顧客が期待した仕事や生活の変化	自社が実現を約束した範囲
営業の商談メモ・録画	営業がした説明、例、条件、保留	顧客が同じ意味で理解したか
見積・提案書	価格、対象、成果物、前提の記載	契約に採用された最終範囲、権限者の合意
契約書・注文書	文書の版・権限を確認した上で、合意した対象、期間、責任、条件	顧客が契約判断で期待した全変化、個別文書の法的評価
製品・実装仕様	現在提供できる機能、権限、制約	現場で入力・確認が行われるか

契約書か商談メモのどちらかを「正しい記録」にして、もう一方を消すのではない。それぞれが何を証明し、何を証明しないかを分ける。契約上の効力や追加合意の要否が不明なら、営業・CSだけで解釈せず、法務や契約責任者へ確認する。

星丘案件で見つかった三つの「引き継ぎ」

会議には、プロダクトマネージャーの佐伯 岳も参加していた。佐伯はモニターの製品仕様を開き、閲覧権限、通知、更新履歴が実装済みであることを示した。

佐伯が守っているのは、実装済み機能の事実だった。それを「現場を分かっていない」の一言で退ければ、今度は営業とCSが製品範囲を曖昧にする。一方で、機能があることだけでは、相談記録が入力され、授業前に読まれ、必要な担当者へ届く状態まで保証できない。

「引き継ぎ」が指すもの	星丘案件での内容	所有する担当	まだ必要な確認
顧客が期待した変化	保護者が前回の相談を説明し直さず、講師が授業前に注意点を確認できる	顧客が指定した窓口と営業が出典・表現を確認	誰のどの相談を、いつまでに確認するか
営業が説明した価値	担当講師が同じ画面で相談記録を共有できる	営業が発言と資料を提示	「できる」が機能か、運用結果か
製品・実装範囲	登録済み記録の閲覧、権限設定、更新通知	プロダクト・実装担当が判定	入力元、対象記録、役割、開始条件

営業・CS引き継ぎシートの8項目

連絡先、契約金額、導入日だけでは、CSは「何を守れば顧客の判断と連続するか」を確認できない。次の8項目を、期待一件につき一行で作る。受領は内容を読める担当へ渡った状態、開始承認は未解決と停止条件を確認した判断であり、同じチェックにしない。

項目	記入する内容	確認質問	空欄のまま渡した時の危険
1. 期待した変化	顧客の仕事・判断・生活がどう変わると期待したか	「導入後、誰の何がどう変われば意味がありますか」	機能名を成功状態とみなす
2. 根拠と決定影響	話者の役割、日時、必要最小限の原文抜粋または参照ID、録画時刻、資料版、顧客確認済みの決定影響	「この期待は選定条件でしたか、参考意見でしたか。誰が確認しましたか」	営業の要約を顧客の約束に変える
3. 合意範囲	契約、権限者が承認した注文書、契約に採用された見積の対象・期間・成果物・条件	「どの版・条項が、誰の権限で最終合意に採用されましたか」	提案途中の案を契約範囲に混ぜる
4. 実装可能範囲	機能、対象データ、権限、連携、支援、対象外、版	「現在の環境で、どこまで再現できますか」	将来機能や手作業を標準機能に見せる
5. 営業説明と条件	営業が伝えた例、留保、前提、未回答、後日訂正	「顧客は何を聞き、営業は何と答えましたか」	契約にない説明を後からなかったことにする
6. 対応状態	一致、要確認、不一致と、その根拠	「期待と範囲を結ぶ条件は確認済みですか」	すべてを『運用で調整』へ送る
7. 解消と顧客確認	確認、範囲変更、代替、保留、合意しない、責任者、期限、顧客回答	「開始前に、顧客が訂正できる形で戻しましたか」	CSが開始後に初めて訂正する
8. 受領・理解確認・開始承認	CS・プロダクト・実装担当の受領者、受け手による再説明、訂正点、未解決、停止条件、開始判断者、各日時	「受け手は何をどう理解し、誰が何を根拠に開始を承認しましたか」	閲覧・受領を理解一致や開始承認とみなす

引き継ぎは5状態に分け、受け手の再説明で理解差を見つける

引き継ぎシートの送信履歴や閲覧履歴は、情報が届いた証拠にはなる。そこから読み取れるのは、情報が指定先へ到達したことまでである。次の5状態を別々に記録する。

状態	確認できること	まだ確認できないこと	次へ進む条件
1. 作成済み	営業が8項目を記入した	原資料との一致、受け手への到達	証拠・版・空欄を営業側で点検する
2. 送信済み	指定した受け手へ送った	閲覧、理解、責任の受入	対象者と閲覧権限を確認する
3. 受領済み	CS・実装担当が受け取り、参照できた	同じ意味で理解したか	受け手が四点を再説明する
4. 理解確認済み	期待、提供範囲、未解決、停止条件の解釈差を訂正した	顧客確認や重大な不一致の解消	責任者・期限と顧客へ戻す内容を置く
5. 開始承認済み	指定された判断者が開始条件を確認した	導入成果、継続利用、顧客満足	試行・導入後の測定計画へ分ける

再説明は受け手を試す口頭試問ではなく、渡し手の要約や用語だけでは見えなかった不足を共同で見つける確認である。受け手は次の四点を資料を見ながら言い直し、渡し手は「合っています」で終えず、原資料と照らして訂正点を残す。

1. 顧客が期待した変化と、その根拠
2. 現在合意・提供できる範囲と、できない・未確認の範囲
3. 未解決ごとの責任者、期限、顧客へ戻す内容
4. 何が未確認なら開始を止め、誰が開始を判断するか

たとえば「顧客は情報共有を期待しています」という再説明では、機能名と期待した変化の違いが消えている。「保護者が説明を繰り返さなくてよい状態を期待している。現在提供できるのは登録済み記録の閲覧と通知で、入力者と確認時点は未確認」と言い直せれば、次に確かめる境界が見える。ここで新しい合意を社内だけで作らず、顧客が訂正すべき内容は顧客へ戻す。

顧客が期待した変化は、機能名ではなく一場面で書く

「情報共有」「業務効率化」「定着支援」では、誰のどの仕事を指すか分からない。次の形にすると、実装範囲との間に残る仕事が見える。

星丘の例なら、「担当講師が、保護者と話す前に、前回相談の注意点を確認でき、保護者が同じ説明を繰り返さなくてよい。城南校の先行導入を選ぶ判断条件の一つ」となる。改善効果が既に出たという記録ではない。開始前に顧客が期待している状態を記述したものだ。

一つの期待を、一つ以上の根拠に対応づける

期待と機能を一行ずつ別々に並べるだけでは、どれがどれを支えるか分からない。一つの期待に、契約記載、実装仕様、営業説明、顧客確認を対応づける。根拠がない欄は「なし」ではなく「未確認」とする。

ずれは「期待値調整」で弱めず、顧客へ選択肢を戻す

不一致が見つかった時、CSへ「期待値を下げてください」と渡すと、営業の説明と顧客の判断が見えなくなる。追加確認、範囲・時期の変更、代替案、合意しない選択を同じ強さで示す。契約範囲、費用、日程、安全、情報セキュリティ、個人情報、権利に影響する不一致は、所管責任者と顧客の確認が終わるまで開始承認へ進めない。開始を妨げない未解決は、根拠、責任者、期限、停止条件を残し、受領だけで完了にしない。

そのまま使える営業・CS引き継ぎテンプレート

次のブロックを案件ごとに複製し、期待一件につき一つ作る。個人情報、録音、契約資料は、取得目的と通知・同意等の根拠、必要最小限の範囲、保存先、閲覧者、保持期間、訂正窓口、削除可否と制約を、自社・顧客の規程と適用法令に合わせる。保護者相談の具体的内容はこの引き継ぎシートに複製せず、必要な業務場面と権限条件だけを記録し、原資料は承認済みの保管先で管理する。

個人情報保護委員会の通則編は、利用目的をできる限り具体的に特定し、取扱状況とリスクに応じた安全管理措置を求めている。学校・委託先・サービス提供者それぞれの立場、第三者提供、委託、越境移転などの該当性は、テンプレートだけからは判定できない。実際の情報と契約関係に基づき、法務・個人情報保護・情報セキュリティの責任者が確認する。

星丘学習サービスの記入例

欄	記入例
期待した変化	城南校の担当講師が保護者対応前に前回相談の注意点を確認し、保護者が同じ説明を繰り返さなくてよい
根拠	顧客側会議の議事録。話者・日時・共有範囲を記録。先行導入の判断条件の一つ
合意範囲	城南校の合意済み役割に、登録済み相談記録の閲覧と更新通知を提供
実装可能範囲	閲覧・権限・通知は対応可能。どの記録を誰がいつ登録し、誰が授業前に確認するかは未確認
営業説明	ミナトが「担当講師が同じ画面で引き継げる」と説明。機能と運用結果の境界を明示できていなかった
対応状態	要確認。機能は一致するが、期待した変化までに必要な入力元・時点・役割が未確認
解消	顧客へ期待した一場面と提供範囲を並べて戻し、開始前の確認会で役割・対象・時点を訂正可能にする
受入	瀬戸と佐伯が受領し、期待、提供範囲、未確認の役割・時点、停止条件を再説明。ミナトの訂正を反映した。顧客確認が記録されるまで確定済み実装タスクと未確認条件を分け、受領・理解確認とは別に開始判断者が承認する

この記入例が示すのは、先行導入の成果や定着ではなく、開始前に残っている確認である。引き継ぎが終わったら、「トライアルの測定、成功・中止条件、現場負担」を別シートで決め、引き継ぎ記録と測定計画を混ぜない。

引き継ぎ会議の進め方｜45分の一例

会議時間に普遍的な正解はない。次は、期待が少数に整理された一案件を確認する例である。期待が多い場合は、一度に読み上げず、契約判断へ影響した項目と高リスクな不一致から扱う。安全、法令、情報セキュリティ、個人情報、権利、契約・費用に関わる論点は45分で結論を急がず、所管担当を加えて保留できる。

時間	行うこと	完了条件	会議でしないこと
0〜5分	今回の開始判断、対象範囲、参加者の責任を確認	何を決め、何は決めないかを全員が訂正できる	案件の成功を宣言する
5〜15分	顧客が期待した変化を、原文と証拠から読む	機能名でなく一場面として残る	営業要約だけで顧客意図を確定する
15〜25分	契約・見積・実装可能範囲に対応づける	各期待が一致・要確認・不一致になる	将来機能や善意の手作業で穴を埋める
25〜35分	ずれの解消方法、責任者、期限を決める	顧客へ戻す選択肢と開始への影響が決まる	CSへ説明のやり直しを丸投げする
35〜40分	CS・プロダクト・実装担当が期待・範囲・未解決・停止条件を再説明し、営業が訂正する	受領者の理解差、未解決、停止条件、開始判断者が記録される	復唱を試験にする、受領や通知を開始承認とみなす
40〜45分	顧客確認文と次の確認日を読み合わせる	顧客が訂正・保留・合意しない入口がある	社内表現のまま顧客へ送る

担当者も交代する場合は、前任・後任からの挨拶例を使い、顧客へ新しい連絡先を伝えます。

ずれを見つけた時の顧客確認文

顧客へ戻す文面は、謝罪文、追加提案、導入案内を一度に詰め込まない。まず自社記録と提供範囲を示し、認識の訂正と選択を求める。重大な不一致、契約変更、費用、責任、法令に関わる場合は、所管部署の確認を経る。

役員向けに入口を短くする必要がある時は、「三行で役員に伝えるテンプレート」の結論・影響・次の判断へつなぎ、詳細と証拠は削除せず後段に置く。条件を説明する順序は「正確さを落とさず営業説明を分かりやすくする」へ分ける。

一次研究から言えること、言えないこと

Tuli、Kohli、Bharadwajの「Rethinking Customer Solutions」は、顧客企業の管理者49人、供給企業の管理者55人への深層面接と、二つのフォーカスグループの管理者21人との議論を基に、顧客がソリューションを製品束ではなく、要件定義、カスタマイズと統合、導入、導入後支援を含む関係的な過程として捉える違いを示した。

これは質的研究から作られた枠組みであり、この8項目テンプレートが解約を減らす、導入成果を上げる、すべての顧客が同じ捉え方をする、と証明した研究ではない。本記事では、機能の受け渡しだけで顧客が期待した変化を引き継いだことにはならない、という問いを立てる範囲で使う。

Carlileの「Transferring, Translating, and Transforming」は、組織内の知識境界を、共通語彙で移せる段階、意味を翻訳する必要がある段階、利害や実務を変換する必要がある段階に整理した概念枠組みである。自動車開発初期の共同ツールを例にしており、営業・CS引き継ぎの効果検証ではない。

本記事では、「引き継ぎ」という同じ語があっても、顧客、営業、CS、プロダクトで意味と守る責任が違う場合、情報転送だけでは足りないと考える補助線に限る。研究名を根拠に会議時間、項目数、成果を普遍化しない。

CRM・CS・プロジェクト管理ツールは「自動要約」より記録境界で比べる

CRMやCS管理、契約・プロジェクト管理ツールを選ぶ時は、引き継ぎたい情報と部門間の責任を記録できるか確認します。実在顧客の情報を持ち込まず、最初から作った架空の案件で、次の8点を実演してもらいましょう。

比較基準	確認する機能・運用	導入前に試すこと	避ける選び方
期待と機能の分離	顧客が期待した変化を機能名と別フィールドで持てる	一つの期待に複数の機能・条件を結ぶ	成功目標欄に一文でまとめる
原文・証拠・版	話者、日時、録画時刻、資料版、契約箇所へ戻れる	AI要約から該当発言と原資料を開く	要約で原文を上書きする
対応関係	期待、契約、実装、営業説明を一対多で結べる	同じ「共有」が別の意味を持つ案件を登録する	添付ファイル一覧だけで済ませる
ずれと開始制御	一致・要確認・不一致、保留、承認条件を持てる	未解決時に開始タスクが自動完了しないか見る	すべてを注意メモにする
部門横断の責任	営業、CS、実装、プロダクトの責任者・期限・受入を分ける	一人の退職・異動後も責任履歴が残るか見る	アカウント所有者一人に集約する
顧客確認と変更履歴	訂正、保留、回答、再合意、変更前後を追える	顧客回答後も以前の記録を監査できるか見る	最新状態だけを保存する
権限・同意・保持	録音、個人情報、契約、社内メモの目的、取得根拠、閲覧、訂正窓口、保持、削除可否を分ける	CSに不要な機密が自動共有されないか見る	全社共有を連携成功とみなす
出力・連携・総費用	CSV・API、移行、教育、保守、AI利用、監査ログの費用	CRMからCS、CSから実装へ同じIDで出力する	月額と画面の見栄えだけで選ぶ

AIは、長い商談から候補発言を探し、引き継ぎシートの下書きを作る補助にはなる。ただし、約束の確定、契約解釈、実装可否、顧客の同意をAIへ委ねない。商談録音、保護者相談、契約資料を外部AIへ入力する前に、承認済みの目的・経路、データ処理条件、保存・学習利用、アクセス権限を確認し、必要最小限にする。出典時刻へ戻れるか、人が訂正・承認できるか、機密情報が保存・外部共有にどう使われるかを確認する。

商談メモに「顧客が期待した変化」を追加する

ミナトは星丘の商談メモを開き、「製品説明」「顧客要望」の間に新しい欄を追加した。

顧客が期待した変化：担当講師が保護者対応前に前回相談の注意点を確認し、保護者が同じ説明を繰り返さなくてよい。城南校の先行導入を選ぶ判断条件の一つ。顧客側議事録の話者・日時・共有範囲を参照。

その下に、契約範囲、実装可能範囲、未確認の役割と時点、顧客確認日を別欄で置いた。「保護者対応の引き継ぎ漏れをなくす」という営業側の要約は削除せず、ミナトの解釈だったと分かる場所へ移した。

星丘側には、期待した変化と現在の提供範囲、開始前に確認する役割・対象・時点が一枚で送られた。顧客側の訂正を反映し、契約・個人情報に影響する不一致が解消されたことを開始判断者が確認した。瀬戸と佐伯は受領欄と開始承認欄を分けて記録した。

リードクラフトの予定表に、「星丘学習サービス城南校・先行導入開始」と、最初の確認会が追加された。画面が使われたか、どの負担が増えたか、ほかの教室へ広げられるかは、まだ何も記録されていない。

営業とCSの引き継ぎでは、契約時に見えていた変化と、現在実装できる範囲を同じ場所に置く。顧客の期待を社内の都合に翻訳して終えず、違いを顧客が訂正し、必要なら所定の変更・保留手続を選べるところまで戻す。

今日の一手

受注済みの一案件を開き、顧客が期待した変化を原文または確認済み要旨で一行だけ抜き出します。その行を契約範囲・実装可能範囲・未確認に対応づけたら、受け手に「期待・提供範囲・未解決・停止条件」を自分の言葉で再説明してもらい、解釈差を一つ直してください。受領済みでも、開始条件を満たさなければ開始承認は止めます。

成功事例に入れる範囲を先に決める

この節が担当するのは、成功事例の記録へ何を残し、どの範囲を共有できる状態にするかです。承認済みの一事例を商談で前後の日常・残った仕事・今回との共通点と相違点へ分けて話す手順は「導入事例を他社の話で終わらせない6欄」へ分けます。

成果だけを引き継ぐと、次の担当者は条件の違いを見落とします。対象、支援、期間、例外を一緒に残し、別の現場へそのまま当てはめない境界を作ります。

S3E02「成功事例の影」— 判断表

元の場面: 成功事例の影

成功事例へ入れる範囲	城南校の事実	書き換えないこと
対象機会	藤森の記録帳を基に確認した、十営業日の31件。定義・締切・重複確認日を併記	登録できた24件を全件とせず、31件も完全網羅と断定しない
集計へ入った範囲	登録24件、事前閲覧21件、未閲覧3件	21÷24を教室全体の引き継ぎ成功率にしない
集計外・例外	夜間電話、代講、紙の記録など7件	例外を利用者の抵抗や操作ミスにしない
追加作業	藤森の自己記録8回・計4時間20分。整理、確認、促し、後追い登録	善意、教育費、初期だけの負担、総工数、法令上の労働時間と推定しない
顧客成果	保護者が説明を繰り返さずに済んだかは未測定	閲覧を最終成果へ置き換えない

S3E02「成功事例の影」— 成功事例は11項目を一つの記録に置く

元の場面: 成功事例の影

成功事例の欄	城南校の記録	読み手が判断できること
1. 課題と期待	講師が対応前に前回相談を確認し、保護者が説明を繰り返さなくてよい状態	何を成果としたい導入か
2. 対象・期間・版	城南校、十営業日、対象業務・機能版・運用開始日	いつ、どの範囲の結果か
3. 母数と集計条件	記録帳を基に確認した対象機会31件。定義・期間・締切・重複確認日を併記し、登録24件を閲覧集計	数字へ入った人・仕事、入らなかった範囲、完全性の限界
4. 比較・基準	導入前の同一定義による基準値は未取得	増減や因果を言えるか
5. 確認できた観測結果	登録24件中21件で所定時点までの事前閲覧ログ	実際に観測した途中の行動
6. 支援・成立条件	権限設定、更新通知、中澤の周知、藤森の記録整理	結果に伴った人・設定・働きかけ
7. 追加負担・費用	藤森の自己記録8回・計4時間20分。未計測範囲と授業準備との競合あり	誰の仕事が増え、何を追加確認するか
8. 例外・未利用	集計外7件、登録済み未閲覧3件。理由は一部未確認	標準条件が成立しなかった場面
9. 未測定・別解釈	保護者の説明反復、理解、対応品質は未測定。周知や個人支援の影響を分離できない	成果と呼ばない範囲、因果の限界
10. 適用条件	同じ相談記録、担当役割、登録時点、支援を用意できるか要確認	他拠点で先に確かめる条件
11. 確認・公開範囲	中澤・藤森・中井が事実を訂正。目的・閲覧者・保管期限を限定。個人・保護者情報と発言引用は非公開	誰が内容を確認し、どこまで使えるか

S3E02「成功事例の影」— 顧客事例・CRM・分析ツールは、きれいな記事生成より証拠の境界で比べる

元の場面: 成功事例の影

比較基準	確認する機能・運用	導入前に試すこと	避ける選び方
対象・母数・除外	対象機会、登録、利用、除外理由を別項目で持てる	31件、24件、21件、7件を同時登録する	最大の率だけをカード表示する
比較・時点・版	基準値、観測期間、機能・運用版を残せる	基準値なしをゼロへ変換しないか見る	導入前後グラフを自動生成するだけ
成果の階層	操作、途中行動、顧客成果、未測定を分ける	閲覧ログを「引き継ぎ成功」へ自動変換しない	一つの成功スコアへ集約する
支援・負担・費用	人の支援、作業時間、追加費、通常業務との競合を結べる	4時間20分を注記でなく集計対象にする	製品利用時間だけで工数を測る
例外・未利用	非利用、集計外、失敗、理由不明を分ける	7件を削除せず理由未確認で残す	成功事例から自動除外する
適用条件の検索	業種、規模だけでなく役割、仕事、支援、例外で探せる	夜間連絡と代講がある教室を抽出する	似た企業ロゴだけを推薦する
証拠・顧客確認	原データ、発言、版、訂正、承認者、公開範囲、期限へ戻れる	社内限定の記録を公開原稿へ混ぜない	AI要約を承認済み引用にする
権限・出力・総費用	個人情報、顧客機密、AI利用、CSV・API、移行、教育、監査費	承認済みの項目だけを出力し、個人・機密情報や再識別につながる少数値を除けるか見る	月額と公開テンプレート数だけで決める