顧客オンボーディングのキックオフ資料は、契約・購入で合意した内容を、双方で進める導入計画に落とし込むものです。顧客の目標、両チームの役割、開始に必要な情報、受け入れの進め方を明らかにします。製品紹介だけでは、この役割を果たせません。

まず、顧客がすでに目指すと合意した成果から始めます。次に、顧客側の作業も含め、そこに至るために必要な仕事を示します。説明内容が固まったら、Presentiでオンボーディング計画をスライドの下書きにし、参加者に合わせて編集します。約束は承認済みの範囲にとどめ、見栄えのよい工程表から新しい約束を生まないようにしましょう。

顧客と導入支援チームが提供する情報を、共通の節目と受け入れ確認につなぐ図
日付が約束に変わる前に、双方が行う作業を見えるようにするのがキックオフの役割です。

会議で何を決めるのかを明確にする

キックオフの終了時には、次に誰が何をするのか、未決定の何が進行を妨げるのかが分かる状態を目指します。購入を促す商談とは目的が違います。営業提案を繰り返したり、導入作業を話す前に機能一覧を説明したりするのは避けましょう。

Asanaのプロジェクトキックオフの解説（英語）では、目標、範囲、成果物、役割、コミュニケーションをそろえることが説明されています。顧客との取り組みでは、役割を双方から示します。自社が提供するもの、顧客が提供するもの、それぞれの成果物を受け入れる責任者を明記します。

最初の導入判断を行える人を招きます。顧客側のスポンサーが出席できないなら、合意済みの目標について誰が代わりに説明できるか、どの判断は本人を待つ必要があるかを確認します。出席していることと、決定権限があることは同じではありません。

具体的な導入例を軸に資料を作る

架空のサービス申請ポータルの導入を例に考えます。顧客は1つのサポートチームで、3種類の申請を扱う試験運用を希望しています。今回の範囲は設定、テスト用データのインポート、試験運用前の演習です。全社展開と申請種類の追加は、この段階には含めません。

目標は、結果を作り上げずに「合意した3種類の申請を試験運用できるよう、サポートチームを準備する」と表現します。目標値、基準値、測定方法に実際に合意していない限り、「解決時間を40%短縮する」とは置き換えません。キックオフで成果の測り方を決めることはできますが、まだ生じていない効果を報告することはできません。

合意事項この例での意味根拠または未確認事項
試験運用の範囲1チーム、明示した3種類の申請承認済みの範囲定義と対象業務フロー一覧
設定対象申請のフォームと振り分け顧客の業務責任者が振り分けルールを確認する
テスト用インポートテスト環境へのサンプルデータ投入顧客のデータ責任者が承認済みのサンプルを提供する
試験運用の準備利用者が合意したサンプル作業を実行する演習記録と受け入れ責任者

参加者が承認済みの範囲を参照できるようにしておきます。表は理解を助けるものですが、契約や正式な変更手続きの代わりにはなりません。

双方の役割を並べて示す

提供側だけの作業一覧では、導入を止めやすい依存関係が見えません。成果物ごとに、作成する担当者、顧客側の情報提供担当者、受け入れ責任者を示します。同じ人が複数を担うことはあっても、役割は明示します。

作業導入支援チームの役割顧客の役割受け入れ確認
振り分け設定合意したルールを設定する業務責任者がルールを提供し、不明点を説明する業務責任者がサンプル申請の経路を確認する
テスト用インポート項目を対応付け、テスト用インポートを実行するデータ責任者が承認済みサンプルを提供し、項目を説明するデータ責任者が合意した照合結果を確認する
試験運用前の演習演習を準備し、問題を記録するチームリーダーが参加利用者の時間を確保する試験運用の責任者が結果と未解決事項を確認する

非公開の実務用資料では、役割の仮置きを確認済みの担当者名に置き換えます。公開記事の例にある役割を、そのまま自社の承認経路として使わないでください。担当者が未定の役割は会議にいる人へ黙って割り当てず、決定が必要な事項として残します。

日付を約束する前に受け入れ基準を合意する

「インポート完了」は、ファイルをアップロードした、レコードを作成した、顧客が結果を確認した、のどれを指す場合もあります。これらは別の状態です。計画段階で、観察できる受け入れの根拠を合意します。

この例では、承認済みのサンプル50件すべてについて、処理結果を確認できることを求めるとします。47件が成功し、3件が失敗したなら、その3件をすべて特定し、理由を説明できて初めて照合が完了します。それでも、インポートが自動的に受け入れ済みになるわけではありません。残った問題を次の工程で許容できるかは、受け入れ責任者が判断します。

同様に、「研修を実施した」と「試験運用チームの準備ができた」は別です。演習では、指定した2人がテスト環境で各申請種類の送信、振り分け、完了処理を行うようにできます。実際の結果と注意点を記録します。これは基準の一例であり、すべてのオンボーディングに共通する要件ではありません。

条件付きの日程は、その条件を見せる

見た目の整った工程表でも、必要な情報がそろっていないことを隠してしまうなら危険です。各節目の横に前提を示します。設定前には承認済みルール、インポートのテスト前には承認済みサンプル、演習前には参加利用者の予定が必要です。

例えば、月曜日に承認済みサンプルが届くことを条件に、木曜日のテスト用インポートを目標とする計画が考えられます。到着が水曜日になったら、木曜日をそのまま緑色にしてはいけません。導入リーダーが残りの準備時間を確認し、日程を再確認するか、順序の変更を提案します。

「合意済みの日付」「計画上の目標」「未設定」の3つを使い分けます。暫定日程には、普通の言葉で理由を添えます。工程表全体を注意書きで埋めず、影響を受ける節目の横に条件を置きましょう。

初週に使える行動一覧を残す

次の行動担当する役割必要な時点完了の根拠
3種類の申請と振り分けを確認する顧客の業務責任者月曜日、設定開始前確認済みの業務フロー一覧
承認済みの50件のサンプルを提供する顧客のデータ責任者月曜日、インポート準備前合意した安全な経路からサンプルを利用できる
項目の対応付けに関する質問を返す導入リーダーサンプル確認後質問ごとの回答担当者が決まっている
試験運用の参加者と演習可能な時間を確認する顧客のチームリーダー演習の予約前参加者名と確定した時間

曜日は説明用です。前提条件を確認してから実際の日付に置き換えます。会議で表を一緒に確認し、誰も発言しなかったことを合意と取り違えないようにします。

作業が止まったときの伝え方も決めます。連絡先、伝える情報、次に判断する時点まで示すと実務で使えます。「必要に応じてエスカレーション」だけでは、この3点が未決定のままです。

7枚のキックオフ資料にまとめる

  1. 目的と目指す状態：今回の段階で何を可能にするのか。
  2. 範囲：含まれる成果物と、特に重要な対象外事項。
  3. 具体例：計画した仕組みの中を通る1件の申請、または利用者の動き。
  4. 双方の役割：作成、顧客側の情報提供、受け入れの責任。
  5. 節目と前提条件：合意済みの日付と条件付き目標の区別。
  6. 連絡方法：作業用の連絡経路、確認会議、問題を決定権者へ届ける方法。
  7. 初週の行動：各行動の担当、期限となる時点、完了の根拠。

詳しい製品デモが判断の妨げになるなら、付録や別の機会に分けます。実績が出た後は、四半期ビジネスレビューの資料（英語）で顧客の目標と実際の成果を比較できます。それは、今ここで導入計画を合意することとは別の役割です。

計画とともに、守るべき範囲も伝える

合意した説明文をPresentiのPaste Textに入力します。架空のプロジェクト計画を作らせるのではなく、編集できる構成を求めます。次の入力例は、顧客側の作業も見えるようにしています。

Presentiの英語版Paste Text画面に顧客オンボーディングのキックオフ説明を入力した例
実際の英語版Paste Text画面を使った入力例です。生成後のスライドや合意済みの導入計画を示すものではありません。

説明用のサービス申請ポータルの試験運用について、7枚の顧客オンボーディング用キックオフ資料を作成してください。範囲は1チーム、3種類の申請、設定、50件のテスト用インポート、試験運用前の演習です。顧客と導入支援チームの役割を分けて示してください。合意済みの範囲と、提案段階の受け入れ基準・条件付きの日程を区別してください。最後に初週の行動をまとめてください。顧客の成果、契約条件、本番開始日、約束した導入所要期間を作り上げないでください。

共有前に、それぞれの担当者が役割に合意しているか、顧客が提案と約束を区別できるかを確認します。双方が同じ言葉で次の行動を説明できる状態になれば、会議で使える資料になっています。