クライアントオンボーダー は何をしますか？
Client Onboarder は、新しいクライアントが送ってくるファイルの山（SOP、トレーニング資料、スクリプト、スプレッドシート、スライドデッキ、通話文字起こし、スクリーンショット）を受け取り、それを計画に変えます。すべてのファイルを読み、それぞれが何を保持しているかを記録し、不足しているものを見つけ、クライアントに尋ねる質問をリストアップし、クライアントに渡せる1ページのキックオフ計画を作成します。新しいエンゲージメントの最初の数日間、クライアントが「これが私たちの持っているすべてです」と言い、構築、コーチング、またはコンサルティングを行う前に何を扱っているのかを知る必要があるときに使用します。
始める前に
-
ビジネスコンテキストファイルを確認する。 プロジェクトファイルとチャット内で、ビジネスコンテキストファイル（またはあなたのビジネスを説明するドキュメント）を探します。そこから次のものを引き出します：
- あなたのビジネス名（両方の出力のヘッダーに使用）
- あなたが提供するもの（サービスやプログラム）と、通常どのようにプロジェクトを進めるか：あなたのフェーズ、通常のタイムライン、チーム内の誰が何をするか
- あなたが通常構築やコーチングに使用するツール
- クライアントとの話し方（キックオフ計画があなたらしく聞こえるようにするため）
ビジネスコンテキストファイルがない場合は、以下の5番目の質問をステップ3のメッセージに追加します。
-
まずプロジェクトコンテキストを読む。 ユーザーがセールスコールの文字起こし、提案書、署名済みのスコープ、またはキックオフノートを共有した場合は、何かを尋ねる前にそれらを読みます。それらは通常、以下の質問のほとんどに答えてくれます。
-
不足しているものだけを尋ねる。 不足している項目をすべて1つのメッセージにまとめ、それぞれに簡単な理由を付けてください。最大5つの質問です：
- クライアントとそのビジネス。 彼らが誰で、何を、誰に販売しているか。同じ文書でも、ビジネスが異なれば意味も異なります。
- あなたが提供するもの。 合意したスコープ。例：営業チーム構築、ファネル再構築、オペレーションクリーンアップ、コーチングプログラム、自動化プロジェクト。すべての関連性評価は、これに照らして判断されます。
- タイムラインと成果物。 開始日、期限（ある場合）、および約束した主なアウトプット。
- ファイル。 チャットまたはプロジェクトにアップロードするか、テキストを貼り付けます。リクエストに以下の3つの注意事項を追加します：
- 最初に確認。 「アップロードする前に、クライアントとの契約でAIツールとファイルを共有することが許可されていることを確認してください。顧客の名前、連絡先詳細、支払いデータ、健康記録を含むものは、列を削除するか、除外してください。Claudeに必要なのは構造であり、個人情報ではありません。」
- 最も読みやすい形式。 文書はPDFまたは.docx、スライドデッキはPDF（ノートが重要な場合はノートページ付きでエクスポート）、シートは.xlsxまたはCSV（.xlsxが開かない場合はタブごとに1つのCSV）、.zipではなく解凍されたファイル。
- リンクと録音。 クライアントがリンク（共有ドライブ、クラウドフォルダ、Wikiページ）を送ってきた場合は、ファイルをダウンロードしてアップロードします（リンクは開けないことが多いため）。録音の場合は、ほとんどの通話およびビデオツールでエクスポートできるため、文字起こしを送信します。
- あなたのビジネス（ビジネスコンテキストファイルがない場合のみ）。 「あなたのビジネス名、および通常どのようにプロジェクトを進めるか（フェーズと標準的な期間）、または「標準的な計画を使用」とお伝えください。」これがないと、ヘッダーとフェーズは推測になってしまいます。
-
クライアントを調べる。 Web検索がオンになっている場合は、コンテキストを得るためにクライアントの公開Webサイトとメインオファーページを読みます。そうでない場合は、ユーザーにクライアントのホームページのテキストまたはオファーの簡単な説明を貼り付けるよう依頼します。
-
1つのメッセージで確認とインベントリを表示する。 ファイルが揃ったら、1つのメッセージで（a）クライアント、スコープ、期限に関するあなたの2～3文の理解と、（b）ステップ1のインベントリを送信します。最後に「これで合っていますか？すべてのファイルを読むべきですか、それともいくつかスキップしますか？」と付け加えます。返信を1回待ちます。これにより、間違ったターゲットを狙った分析の無駄なパスを防ぎます。
-
ユーザーが「そのまま実行して」と言った場合、 与えられたもので作業を進め、確認メッセージをスキップし、すべてのファイルを読み、監査の先頭にあなたの前提をリストします。
仕組み
以下の手順を順番に実行します。目標は、「ここに乱雑なファイルの山があります」から「これが私たちが持っているもの、不足しているもの、そしてこれから行うことです」までを1回のパスで行うことです。
ステップ1. インベントリを構築する
詳細を読む前に、受け取ったすべてのファイルをリストします。これは、あなたのフィードバック（始める前のステップ5）と同じメッセージに含めます。表示するもの：
- ファイルの総数
- タイプ別の数（ドキュメント、PDF、スプレッドシート、スライド、画像、オーディオ、ビデオ、その他）
- ファイル名またはフォルダ名からわかるフォルダ構造
- 開けない、または読めないファイル：文字起こしのない録音、テキストのないスキャンまたはロックされたPDF、開かない.zip、届かなかった.pptxまたは.xlsxファイル、壊れたファイル、アクセスできないリンク。それぞれを名前で指定し、代わりに必要なもの（通常はPDF、CSV、または解凍されたファイル）を伝えます。
- 明らかな重複またはバージョンのペア（「Sales Script v2」と「Sales Script FINAL」など）
チャットが1回で受け入れられるよりも多くのファイルがある場合は、最も重要なものから順にバッチで依頼します。SOP、フレームワーク、スクリプトをテンプレートや管理用ドキュメントよりも優先します。
ステップ2. すべてのファイルを読む
これがこのスキルの核心です。ユーザーがスキップするように依頼したものを除き、すべてのファイルを完全に読みます。ファイル名から要約することは決してしません。ファイルごとに、以下を記録します：
| フィールド | 記入内容 |
|---|---|
| タイトル | ファイル名、ユーザーがリンクを提供した場合はそのリンクも |
| タイプ | SOP、トレーニング資料、スクリプト、テンプレート、スプレッドシート、スライドデッキ、録音、契約書、スクリーンショット、その他 |
| 目的 | このファイルの目的を一文で |
| 主要コンテンツ | 内部にある最も重要なもの：フレームワーク、手順、数値、ルール、用語、責任者 |
| 関連性 | 確認したスコープに照らして、HIGH、MEDIUM、またはLOW |
| 実用的な洞察 | 構築、コーチング、または推奨する内容を変えるもの |
各タイプの読み方：
- ドキュメント、PDF、テキスト： すべて読みます。長いファイルの場合は、最初に構造（見出し）を把握し、次にスコープに関係する詳細を把握します。
- スプレッドシートとCSV： タブ、列名、いくつかのサンプル行、および数式や計算フィールドを記録します。シートが何を追跡し、誰が更新しているように見えるかに注意します。数式が表示されない場合は、数値がどのように計算されたかを推測するのではなく、そのように述べます。
- スライドデッキ： 存在する場合はスピーカーノートを含め、すべてのスライドを読みます。ノートが届かなかった場合は、そのように述べます。
- 画像とスクリーンショット： それらが何を示しているか（ダッシュボード、図、組織図、ロゴ）を述べます。それらの中のテキストを読みます。
- 録音： 文字起こしが共有された場合はそれを読みます。そうでない場合は、ファイルを「未レビュー（文字起こしが必要）」とマークします。
20ファイル以上の場合は、5～7ファイルずつバッチで読みます。各バッチの後、進行状況を示す5行程度のメモ（処理済みファイル、これまでの主な発見）を投稿し、会話が長くなった場合に情報が失われないようにします。完全なファイルノートはそこで繰り返さないでください。それらは最終監査に属します。
ステップ3. 相互参照
すべてのファイルが読まれたら、それらを横断して確認します：
- 共有フレームワーク： 複数のファイルに現れる方法、手順、またはモデル。これらは、クライアントが実際にどのように運営しているかを示しています。
- 用語集： クライアント独自の用語、頭字語、およびオファー、ステージ、役割の名前。計画と作業は、彼らの言葉を使用する必要があります。
- 矛盾： 同じプロセス、数値、価格、または責任者について異なることを述べている2つのファイル。両方を引用し、ファイル名を挙げます。これらは、今誰もキャッチしなければ後で問題を引き起こします。
- 最新 vs 旧式： バージョンが競合する場合、日付、ファイル名、またはコンテンツに基づいてどちらが最新のように見えるかを述べ、クライアントが確認するようフラグを立てます。
- 責任者： 何に対して誰が責任者として指名されているか、そしてそのファイル。
ステップ4. ギャップを見つける
欠けているものは、しばしば存在するものよりも価値があります。ファイルを、この種のプロジェクトに通常必要とされるものと比較します。これを開始リストとして使用し、スコープに合わせて調整します：
| プロジェクトタイプ | 見られることが期待されるもの |
|---|---|
| 営業（設定、クロージング、営業チーム） | コールスクリプトまたはフレームワーク、オファーと価格設定、異議対応ノート、通話録音または文字起こし、パイプラインステージ、現在の見込み率と成約率、誰が何を販売しているか |
| マーケティングとファネル | オファーとオーディエンスの説明、現在の広告、ページ、メール、トラフィックソース、ステップごとのファネル数値、証拠（結果、 testimonial）、ブランドガイドライン |
| オペレーションとSOP | プロセスマップまたはSOP、役割と組織図、使用中のツールと誰がアクセス権を持っているか、ハンドオフポイント、現在のボトルネック、追跡しているメトリクス |
| コーチングまたはトレーニングプログラム | プログラム概要、カリキュラムと教材、サインアップから終了までのクライアントジャーニー、チェックインと進捗追跡、成功事例、コーチまたはチーム名簿 |
| 自動化またはテクノロジー構築 | 現在のツールリスト、管理者アクセス、データソースとデータの保存場所、置き換える手動ステップ、ボリューム（リード数、コール数、注文数）、セキュリティまたはコンプライアンスの制限 |
すべてのギャップを3つのレベルのいずれかに分類します：
- クリティカルなブロッカー： これらなしでは開始できません。それぞれがなぜブロックするのかを説明します。
- 立ち上げ前に必要： 開始はできるが、完了または公開することはできません。
- あると便利： 作業をより良くするが、必須ではない。
ステップ5. 未解決の質問を書く
ギャップ、矛盾、不明確な点をクライアントへの質問に変換します。優先度順に並べ、ブロッカーを最初にします。各質問は、その質問が発生したファイルを指名します。可能な限りクライアントが一言で答えられるように質問を書きます（例：「チームは現在どのオンボーディングスクリプトを使用していますか？「Onboarding v2」または「New Client Script」？」）。重要な質問だけに絞ります。10の鋭い質問は、30の曖昧な質問より優れています。
ステップ6. キックオフ計画の草案を作成する
すべてをクライアント向けの1ページの計画に凝縮します。これは計画であると同時にセールスツールでもあります。クライアントに、あなたが彼らのビジネスを理解し、明確な道筋を持っていると感じさせるものでなければなりません。用語集から彼らの言葉を使用します。以下の部分から構成します：
- 課題： 彼らが抱える問題とそれが今重要な理由を、2～3文で。
- 解決策： あなたが提供するものを、2～3文で。
- 作業範囲： 主要な成果物の短いリスト。合意されたもののみ。スコープ外のアイデアは監査セクション7に記載し、ここには記載しません。
- フェーズ別計画： このプロジェクトと、あなたの通常の作業方法（ビジネスコンテキストファイルまたはユーザーの回答から）に合わせた3つまたは4つのフェーズ。各フェーズに目標、主なアウトプット、大まかなタイミングを設定します。通常のフェーズが提供されていない場合は、ディスカバリー / 構築または設計 / 立ち上げ / レビューを使用し、監査セクション7でこれが提案された構造であることを記載します（計画では決して言及しないでください）。合意されたタイムラインがない場合は、日付をでっち上げるのではなく「タイミングは確認中」と書きます。
- 主要メトリクス： 成功の定義。クライアント自身のファイル（彼らの数値、彼らの目標）またはユーザーから。クライアントまたはユーザーが提供していない目標数値を計画に決して入れないでください。現在の数値がない場合は「ベースラインを週1で測定」と書き、目標がない場合は「目標はキックオフ時に一緒に設定」と書きます。あなたが提案したい目標は、ユーザーの承認を得るために監査セクション7に記載します。
- お客様からのご提供物： ステップ4からのブロッカーとアクセス項目を、平易なクライアント言語で。誰から： ファイルが指名している人物、または誰も指名していない場合は「あなたのチーム」。いつまでに： それを必要とするフェーズ（例：「フェーズ1の前に」）；カレンダー日付は合意されている場合のみ；不明な場合は「確認中」。
- 関連ツール： 作業が触れるプラットフォーム。ファイルからのクライアントの現在のツールと、ビジネスコンテキストファイルからのあなたのツールを使用します。
内部メモ、疑念、「ファイルはめちゃくちゃです」などは記載しないでください。それらは監査に属します。ユーザーがビジネス名を決して提供しなかった場合は、プレースホルダーを残したり、でっち上げたりするのではなく、ヘッダーの「作成者」の部分を削除します。
ステップ7. 作業を確認する
何かを引き渡す前に：
- カバレッジ： インベントリのすべてのファイルが、読めなかったものやスキップするように言われたものを含め、ステータスとともに監査に表示されている。
- 正確性： キックオフ計画のすべての主張は、ファイルまたはユーザーから提供された情報に基づいている。
- でっち上げがないこと： 計画には、クライアントまたはユーザーが提供していない数値、日付、責任者、フェーズ方法が含まれていない。提案は監査セクション7に記載する。
- ギャップ： ギャップリストは、確認したスコープに対して理にかなっている。
- トーン： キックオフ計画は、クリーンで自信に満ちて読め、内部的なものが残っていない。
失敗したものがあれば修正し、その後提供します。
得られるもの
2つのアウトプットを、この順序で。両方をチャットで提供します。ファイル作成がオンになっており、ユーザーが要求した場合は、それぞれをダウンロードして送信できる.docxまたはPDFとして保存します。
長い監査は分割されます。 約12ファイルを超える場合は、3つのメッセージで提供します：メッセージ1 = 監査セクション1と2；メッセージ2 = セクション3から7；メッセージ3 = キックオフ計画。各部分の最後に「次の部分に進むには「続ける」と入力してください。」と付け加えます。セクション2だけが依然として長すぎる場合は、ファイル番号で分割し、同じプロンプトを使用します。ファイル作成がオンになっている場合は、完全な監査を.docxとして保存して貼り付ける代わりに提供し、キックオフ計画だけを貼り付けることを提案します。
アウトプット1：ファイル監査（内部用）
# [クライアント名]：ファイル監査
作成者：[あなたのビジネス名] | [日付]
[X] ファイル受信 | [Y] 完全読了 | [Z] 一部読了、未レビュー、またはスキップ（ステータスを参照）
スコープ：[確認したスコープを一行で]
前提：[何かを推測しなければならなかった場合のみ]
## 1. インベントリ
| # | ファイル | タイプ | 関連性 | ステータス |
ステータスは次のいずれか：完全読了 / 一部読了（理由） / 未レビュー（必要なもの） /
ご依頼によりスキップ / #Nの重複
## 2. ファイルごと
### 1. [ファイル名]
タイプ：[タイプ] | 関連性：[HIGH / MEDIUM / LOW]
目的：[一文]
- [主要コンテンツ]
- [実用的な洞察]
（すべてのファイルで繰り返し、フォルダがある場合はフォルダごとにグループ化）
## 3. 相互参照
共有フレームワーク：[リスト]
用語集：
| 彼らの用語 | 意味 |
矛盾：
| トピック | ファイルAの記述 | ファイルBの記述 | 最新に見える方 |
責任者：
| 領域 | 指名された責任者 | ファイル |
## 4. 不足しているもの
### クリティカルなブロッカー
- [項目]：[なぜブロックするか]
### 立ち上げ前に必要
- [項目]
### あると便利
- [項目]
## 5. [クライアント名]への未解決の質問
| # | 質問 | 発生元（ファイル） | 優先度 |
## 6. トップ3の takeaways
[3つの最も重要な発見。スコープがそれを示唆している場合は、推奨される次のステップを含める]
## 7. 監査ノート（内部用）
- [キックオフ計画に含めなかったスコープ外のアイデア]
- [あなたが推奨する目標（例：「セールスサイクルを平均45日から30日に短縮することを提案します。承認をお願いします。」]）
- [「ファイルはめちゃくちゃです」の代わりに使用する、クライアントのファイル整理に関する平易な観察]
- [計画をカスタマイズするために検討したが却下した代替アプローチ]
- [キックオフ計画のフェーズ構造が標準的な提案であり、あなたの会社の標準ではない場合のその旨のメモ]
アウトプット2：キックオフ計画（クライアント向け）
# [クライアント名]：キックオフ計画
作成者：[あなたのビジネス名] | [日付]
## [課題を2～3文で]
## [解決策を2～3文で]
## 作業範囲
- [成果物1]
- [成果物2]
- [成果物3]
## 計画
### フェーズ1：[フェーズ名] | [大まかな期間、または「確認中」]
目標：[このフェーズの目標]
アウトプット：[主な成果物]
### フェーズ2：[フェーズ名] | [大まかな期間、または「確認中」]
目標：[このフェーズの目標]
アウトプット：[主な成果物]
### フェーズ3：[フェーズ名] | [大まかな期間、または「確認中」]
目標：[このフェーズの目標]
アウトプット：[主な成果物]
（必要に応じてフェーズ4）
## 主要メトリクス
- [メトリクス1]：[ベースラインまたは目標の状態]
- [メトリクス2]：[ベースラインまたは目標の状態]
- [メトリクス3]：[ベースラインまたは目標の状態]
## お客様からのご提供物
| 項目 | 誰から | いつまでに |
|---|---|---|
| [ブロッカーまたはアクセス項目] | [ファイルからの人物名、または「あなたのチーム」] | [フェーズ名の前、または「確認中」] |
| [別の項目] | [人物名] | [フェーズ名の前] |
## 関連ツール
[ツール1]、[ツール2]、[ツール3]、[ツール4]