sales-agency-outbound

エージェンシー向けマルチクライアントアウトバウンド

リードジェネレーションエージェンシー向けのアウトバウンドインフラストラクチャについて、クライアントの分離やドメイン戦略から、大規模なウォームアップ、オンボーディングの手順書、クライアント横断のレポートまで、設計、拡張、運用を支援します。このスキルは特定のツールに依存せず、Smartlead、Instantly、Mailshake、複数ツールの併用を対象とします。

Step 1 — コンテキストの収集

references/learnings.md が存在する場合は、蓄積された知識を確認するため、最初に読み込んでください。

ユーザーに質問します。

1. 現在、または今後、何社のクライアントにサービスを提供しますか？

   • A）立ち上げ期 — 1〜3社
   • B）成長期 — 4〜10社
   • C）拡大期 — 10〜25社
   • D）大規模エージェンシー — 25社以上

2. クライアントあたりの一般的な送信量はどのくらいですか？

   • A）少なめ — 1日あたり100通未満
   • B）標準 — 1日あたり100〜500通
   • C）大量 — 1日あたり500〜2,000通
   • D）クライアントによって大きく異なる

3. どのツールを使用していますか？

   • A）Smartlead（メールボックス数無制限、マスター受信トレイ）
   • B）Instantly（一括ウォームアップ、シンプルなUI）
   • C）Mailshake（Lead Catcher、CRM 連携）
   • D）Apollo（見込み客の開拓＋シーケンス）
   • E）複数のツール — 説明してください
   • F）まだ決めていない

4. 現在のクライアントのオンボーディングプロセスはどのようなものですか？

   • A）場当たり的 — 標準的なプロセスがない
   • B）大まかなチェックリストはあるが、一貫性がない
   • C）文書化され、繰り返し実行できる
   • D）ゼロから始める — プロセスを構築する必要がある

5. 現在、最大の課題は何ですか？

   • A）インフラストラクチャを初めて設定すること
   • B）あるクライアントの問題が他のクライアントに影響すること（相互汚染）
   • C）拡大 — 運用業務を比例して増やさずにクライアントを増やすこと
   • D）レポート — クライアントがより詳しい状況把握を求めている
   • E）複数のドメイン／クライアントにまたがる配信到達性
   • F）その他 — 説明してください

6. ホワイトラベル化は必要ですか？（クライアント向けのブランディング）

7. チーム構成はどのようになっていますか？（創業者1人、小規模チーム、クライアントごとの専任アカウントマネージャー）

ユーザーのリクエストにすでにこれらの情報の大部分が含まれている場合は、該当するステップに直接進んでください。 合理的な前提を明示したうえで、最善の回答をまず提示し、最後に重要度の高い確認事項を1〜2点だけ質問してください。完全なコンテキストがそろうまで回答を保留しないでください。

Step 2 — アーキテクチャの決定

詳細なモジュールのドキュメント、料金、連携、データモデルについては、references/platform-guide.md を読んでください。

プラットフォームガイドの詳細はもう必要ありません。ユーザー固有の状況に集中してください。

Step 3 — 実行可能なガイダンス

ユーザーの課題に基づき、インフラストラクチャの分離、ドメイン戦略、ウォームアップのスケジュール、クライアントのオンボーディング、レポートの設定、またはプラットフォーム固有の実装について、具体的な推奨事項を提示してください。参考データにはプラットフォームガイドを使い、その後はエージェンシーの状況に合わせた、実行可能な次のステップに重点を置いてください。

注意点

• クライアント間で送信ドメインを共有しないでください。 あるクライアントの評判が急落すると（バウンス率の上昇、スパム報告、ブラックリスト登録など）、そのドメインを共有するすべてのクライアントに悪影響が及びます。年間12ドルのドメイン費用は、5社分の評判を再構築するコストに比べればわずかです。

• クライアントごとのウォームアップを省略しないでください。 新しいドメインには、メールボックスの使用年数にかかわらず、個別にウォームアップが必要です。新しいドメインで既存のメールボックスを再利用する場合でも、そのドメインの評判はゼロです。ウォームアップの全スケジュールに従ってください。

• 見栄えだけの指標を報告しないでください。 開封数やクリック数ではなく、予約されたミーティング数や創出されたパイプラインを報告してください。開封数を重視するクライアントは、プロセスを信頼する代わりに件名を細かく管理しようとします。どの指標が重要か、オンボーディング時に期待値を設定してください。

• すべてのクライアントに単一のZapierアカウントを使わないでください。 請求、レート制限、エラー処理は、1つのアカウント内のすべてのZapに影響します。あるクライアントの連携が壊れて再試行が発生すると、Zapierのタスク上限を使い切り、他のすべてのクライアントの連携まで壊れる可能性があります。Zapierアカウントを分けるか、専用の連携レイヤーを使用してください。

• 自己改善：ここで扱われていないことに気づいたら、今日の日付を付けてreferences/learnings.mdに追記してください。

特定のプラットフォームスキルを推奨する前に

このスキルは、複数のプラットフォームにまたがる戦略領域を扱います。特定のプラットフォームスキルをユーザーに案内する前に（## Related skillsに記載されている/sales-mailshake、/sales-klaviyo、/sales-apolloなどの/sales-{platform}）、まずそのプラットフォームスキルの実際のSKILL.mdを読んでください。## Related skillsの1行の説明は候補を特定するには十分ですが、推奨を決定したり、それを適切に呼び出すプロンプトを作成したりするには不十分です。

読み方：

• ~/.claude/skills/{skill-name}/SKILL.mdがローカルに存在する場合は、それをReadしてください。
• sales-*スキルの場合は、このリポジトリから直接WebFetchしてください：https://raw.githubusercontent.com/sales-skills/sales/main/skills/{skill-name}/SKILL.md。例：sales-mailshakeの場合は、https://raw.githubusercontent.com/sales-skills/sales/main/skills/sales-mailshake/SKILL.md。
• サードパーティ製の sales-*以外のスキルの場合は、インストール済みであれば~/.claude/skills/sales-do/references/skill-sources.mdで{org}/{repo}を確認し、そのリポジトリ内の同じskills/{skill-name}/SKILL.mdパスから取得してください。

読んだ後は、SKILL.mdに記載された具体的な内容（対象範囲、サブフロー、argument-hintの形式、または「使用しないでください」という否定条件など）に基づいて推奨してください。生成する呼び出しは、プラットフォームスキルのargument-hintに沿わせてください。プラットフォームスキルがユーザーの状況に合わない場合は、別のスキルに切り替えるか、適切でないスキルを推奨するのではなく、ここで直接質問に対応してください。

関連スキル

• /sales-smartlead — Smartleadプラットフォームのヘルプ（SmartSenders、SmartInfra、キャンペーン、API）
• /sales-deliverability — ドメイン認証、ウォームアップスケジュール、受信トレイへの到達状況
• /sales-cadence — アウトバウンドのケイデンスとメールコンテンツの設計
• /sales-prospect-list — クライアントのキャンペーン向けに、対象を絞った見込み客リストを作成
• /sales-integration — Webhook、Zapier、APIを使用してアウトバウンドツールをCRMに接続
• /sales-mailshake — Mailshakeプラットフォームのヘルプ
• /sales-reply — Reply.ioプラットフォームのヘルプ（クライアント数無制限のAgencyプラン）
• /sales-woodpecker — Woodpeckerプラットフォームのヘルプ（クライアントごとの管理が可能なAgencyパネル）
• /sales-do — どのスキルを使うべきかわからない場合は、営業に関するあらゆる目的に適したスキルをルーターが選びます。

例

• 「Smartleadで最初の3クライアント」 → クライアントごとに専用ドメインを割り当て（各2個）、SmartSenders経由でドメインごとに3～5個のメールボックスを用意し、分離用のクライアントワークスペースを作成し、段階的なウォームアップ計画を立て、フェーズ1～3のオンボーディングチェックリストを作成します
• 「クライアントがブラックリストに登録され、他のクライアントの率も低下している」 → 共有ドメイン／IPが相互汚染の原因かどうかを診断し、影響を受けたクライアントを一時停止し、ブラックリストを確認し、新しいドメインを用意して再ウォームアップし、今後はクライアントごとに厳格に分離する設計にします
• 「再現可能なオンボーディングプロセスを構築する」 → フェーズ1～3のプレイブック（14～21日）、再利用可能なチェックリストテンプレート、/sales-prospect-list、/sales-cadence、/sales-integration への引き継ぎ、クライアント向けキックオフアンケート、マイルストーンの追跡