「同じ作業を毎日繰り返している」「フォローアップを忘れた」「データが手動入力のまま放置されている」——これらはすべて、自動化で解決できる問題だ。HubSpot のワークフローを正しく設計すれば、リードのアサイン・ステージ変更時の通知・塩漬け商談のアラート・CS へのハンドオフまで、営業オペレーションの反復作業を人間の判断なしに正確に実行し続ける仕組みが作れる。この章では、Sales Hub の自動化設計を「何を・いつ・どう自動化するか」という視点で体系的に解説する。
HubSpot のワークフローは 「トリガー（いつ起動するか）→ 条件（誰に適用するか）→ アクション（何をするか）」の3要素で構成される。この3つの組み合わせで、ほぼあらゆる営業オペレーションの自動化が実現できる。ワークフローを設計する前に、この構造を正確に理解することが重要だ。
| 要素 | 役割 | Sales Hub での代表例 |
|---|---|---|
| トリガー | ワークフローを起動する「きっかけ」。プロパティの変更・フォーム送信・ページ訪問・日付・メールアクティビティなどが利用できる | 商談ステージが「比較検討」に変わった / リードスコアが 60 を超えた / 見積書が送付された |
| 条件 | トリガーが発火した後、「さらに絞り込む」フィルタ。「もし〜ならば」という分岐ロジックを追加できる | 金額が 100万円以上の場合 / 担当者が特定チームのメンバーの場合 / 業種が SaaS の場合のみ |
| アクション | 条件を満たした場合に実行される処理。プロパティ更新・タスク作成・メール送信・通知・Slack 送信・シーケンスエンロールなど多数 | 担当者にタスクを作成 / Slack チャンネルに通知 / ライフサイクルステージを更新 / シーケンスを停止 |
1:1 営業メールのトリガー（Private Beta・2026年1月）と Buyer Intent シグナルトリガー（Dec 2025）は最新の追加機能だ。特に 1:1 メールトリガーは営業自動化の概念を大きく変える可能性を持っており、一般公開後は Sales Hub の自動化設計の標準的な構成要素になるだろう。現時点（2026年3月）では Beta 参加者のみが利用できる。
インバウンドリードが入ってきたときに「誰に渡すか」を手動で判断していると、スピードとフェアネスの両方を失う。リードローテーション（Lead Rotation）は、定義されたルールに従って新規リードを営業担当者に自動アサインする機能だ。HubSpot では Professional 以上でワークフローのアクション「リードを自動的に割り当てる」として利用できる。
| リードの属性 | アサイン先 | ワークフローの条件設定 |
|---|---|---|
| 従業員数 500名以上 | エンタープライズ担当チーム（ラウンドロビン） | Number of Employees ≧ 500 → Enterprise チームのラウンドロビン |
| 従業員数 50〜499名 | SMB 担当チーム（ラウンドロビン） | Number of Employees between 50 and 499 → SMB チームのラウンドロビン |
| 既存顧客の紹介リード | 既存顧客の担当 CS / 営業に優先アサイン | Original Source = Referral かつ Referrer Company known → 紹介元顧客の担当者に直接アサイン |
| ICP 外の業種 | SDR（アウトリーチ担当）にアサインして事前資格確認 | Industry is not in ICP リスト → SDR チームにアサイン後、資格確認後に AE へ転送 |
| 担当者のアサインが24時間後も未完了 | マネージャーにエスカレーション通知 | Contact Owner is unknown → 24時間待機 → マネージャーへ Slack 通知 |
「MQL が入ってから何時間以内に初回コンタクトを取るか」というリードレスポンスタイム SLA を自動で追跡・管理できる。アサインから X 時間後に「未コンタクト」の場合は担当者へのリマインダー → さらに X 時間後にマネージャーへのエスカレーション、というフローを組む。研究ではリードへの初回連絡が5分以内の場合、30分後と比べてコンタクト率が 100倍以上になるというデータもある。SLA の自動管理は投資対効果が非常に高い自動化だ。
パイプラインを圧迫する最大の要因のひとつが「塩漬け商談」——長期間ステージが動かず、担当者も忘れかけている商談だ。手動でのパイプラインレビューでは見落とされやすいが、ワークフローで自動検知・自動アラートを設定することで、塩漬け商談をシステムが能動的に「浮かび上がらせる」ことができる。
| ステージ | アラート発火日数 | エスカレーション日数 | 推奨対処アクション |
|---|---|---|---|
| 初回接触 | 7日 | 14日 | フォローアップシーケンスを開始。コールを優先する |
| 課題特定 | 10日 | 17日 | 次のアクション（提案日程）を確定させるコールを実施 |
| 提案・デモ | 10日 | 17日 | 追加資料の提供 / 別角度のアプローチメール / チャンピオンへの確認 |
| 比較検討 | 14日 | 21日 | マネージャー同席の上位者コールを設定。ROI 資料・事例を再提示 |
| 契約交渉 | 7日 | 14日 | 法務・購買部門への直接コンタクト。期限設定（年度末など）の活用 |
クローズ予定日を過去に放置している商談はフォーキャストを大きく歪める。「クローズ予定日が今日より前かつ商談がオープン状態」という条件で毎週月曜日に実行するワークフローを設定し、担当者に「クローズ予定日の更新または失注処理」を求めるタスクを自動作成しよう。これだけでフォーキャスト精度が劇的に改善される組織が多い。
Sales Hub を導入したすべての組織で設定を推奨する「必須ワークフロー」を10個のレシピとして整理した。それぞれのトリガー・アクション・推奨プランを示す。自組織の状況に合わせてカスタマイズしてほしい。
ワークフローは増えるほど管理が難しくなる。「なぜこのワークフローが動いているのかわからない」「重複した処理が走っている」「テストせずに本番でバグを出した」——これらは命名規則・テスト習慣・ドキュメント管理の不備から生まれる。ワークフローの数が増える前に、ガバナンスの基盤を作っておくことが RevOps の重要な仕事だ。
| アンチパターン | 問題点 | 正しい設計 |
|---|---|---|
| 「すべてのコンタクトに再エンロール可」に設定 | 同じ人に同じメールが何度も送られたり、同じタスクが重複作成される | 再エンロールは意図的な場合のみ有効化。デフォルトは「1回のみ実行」に設定する |
| テストせずに本番有効化 | 数千件のコンタクトに誤ったメールが一斉送信されるリスク | テストコンタクトで必ず1件試してからバッチ適用。大規模な場合は段階的に適用する |
| ワークフローの連鎖（スパゲッティ） | ワークフロー A の出力がワークフロー B をトリガーし、B が C を起動…と連鎖が複雑化して追跡不能になる | 1つのワークフローで完結させる設計を優先する。連鎖させる場合は必ず文書化する |
| プロパティの上書きを無条件に実行 | 「Owner を上書き」アクションが既存の担当者をリセットしてしまう | 「プロパティが未設定の場合のみ」の条件を必ず付加する |
| 削除済みユーザーを承認者・通知先に設定 | 退職した担当者に通知が飛び続け、タスクが放置される | 担当者の退職時にワークフローのユーザー設定を必ず更新する。退職者チェックリストに組み込む |
自動化の前に「何が起きたとき（トリガー）」「誰に（条件）」「何をするか（アクション）」を日本語で整理してから HubSpot に実装する。設計なき自動化はスパゲッティを生む。
ICP 属性（規模・業種・ソース）に基づく担当者への自動アサイン、アサイン後のレスポンスタイム SLA の自動追跡をセットで設計する。初回連絡の速度が商談化率に直結する。
14日停滞でアラート・21日停滞でマネージャーエスカレーション・クローズ予定日超過は週次で自動抽出。人間が「気づく」のを待つのではなく、システムが「浮かび上がらせる」設計にする。
MQL アサイン・商談初期タスク・Closed Won 処理・失注後ナーチャリング・更新90日前アラートは最優先で設定する。Intent シグナルトリガーは 2025年12月以降の新機能として活用する。
「[オブジェクト] [目的] [バージョン]」の命名規則・本番前のテスト必須・四半期の棚卸し・変更権限の RevOps 集約——この4つを徹底することでワークフローの品質と管理性を維持できる。
「再エンロール無制限」「テストなし本番適用」「ワークフロー連鎖」「プロパティ無条件上書き」「退職者への通知設定放置」の5つのアンチパターンを設計時に意識的に排除する。