ワークフローオートメーション：初日から実装すべき10のCRMオートメーション

12人のインサイドセールスチームが2週間でHubSpot CRMにこれら10のオートメーションを追加しました。オートメーション前、担当者は管理作業に1日平均45分かけていました：インバウンドリードの手動ルーティング、デモ後のフォローアップタスク作成、テリトリー変更後の案件オーナー更新、クローズ日のズレの記録。オートメーション後：1日23分。チーム全体で週22時間が実際の営業活動に解放されました。

計算はシンプルです。問題は、ほとんどのチームが3つ（リード割り当て、案件作成、ウェルカムメール）を自動化して完了と思ってしまうことです。このガイドでは実際に効果のある10のオートメーションを説明します。

CRMオートメーションの考え方

すべてのCRMオートメーションには同じ3つの部分があります：

トリガー：オートメーションを開始するイベントまたは条件。新しいコンタクトが作成された。案件ステージが変わった。フィールド値が更新された。日付が到来した。

条件：オートメーションが発動するタイミングを絞るオプションのフィルター。「リードソース = インバウンドWebの場合のみ」「案件金額 > 50万円の場合のみ」「従業員数 > 50人の場合のみ」

アクション：何が起きるか。タスクを作成する。通知を送る。フィールドを更新する。シーケンスに登録する。担当者にルーティングする。

アクションについて心配する前にトリガーと条件を正しく設定してください。多くの壊れたオートメーションはアクションが間違っているからではありません。トリガーが広すぎる（すべてにタグが付く）か条件がルーズすぎる（間違ったレコードが影響を受ける）ために壊れています。

HubSpotでは、これらはWorkflows（オートメーション → Workflows）で構築します。SalesforceではFlow Builderで構築します。Pipedriveでは「オートメーション」の下にあります。ロジックは同じですがUIは異なります。

オートメーション1：テリトリーまたはラウンドロビンによるリード割り当て

トリガー：リードステータス = 「新規」のコンタクトが作成された 条件：リードソースが空欄でない（ソースなしで手動作成されたコンタクトを除外） アクション：テリトリー（都道府県/地域フィールド）に基づいてコンタクトオーナーを割り当てるか、担当者リストをローテーションする

このオートメーションは手動リードルーティングのキューを排除します。これがなければ、誰か（通常はマネージャーかSDRリード）がリードキューを確認して担当者に名前を引っ張ります。その人がボトルネックになります。

HubSpotでの設定：ラウンドロビンには「レコードをオーナーにローテーション」ワークフローアクションを使用し、特定の地域に特定の担当者を割り当てるにはテリトリーフィールド値による分岐を追加します。

Salesforceでの設定：アサインメントルールを使用します（Setup下のリードアサインメントルール）。テリトリー/Industry/サイズ基準のルールエントリを特定の担当者またはキューと担当者として作成します。

Pipedriveでの設定：オートメーション → 「案件が作成された」または「リードが追加された」によってトリガーされるワークフローを作成し、フィルター基準に基づいてオーナーを割り当てるアクションを設定します。

重要な条件：ソースが入力されているリードにのみこれを発動させてください。管理者またはインポートで作成されたコンタクトはルーティングが不要な場合があります。

オートメーション2：見込み顧客からの案件作成

トリガー：コンタクトのプロパティ「リードステータス」が「見込み顧客」（または相当するステージ名）に変わった 条件：このコンタクトにすでにオープン案件が関連付けられていない アクション：案件レコードを作成し、コンタクトと企業に関連付け、案件オーナー = コンタクトオーナーに設定し、Pipelineステージ = 最初のアクティブステージに設定する

このオートメーションは担当者が手動で案件を作成せずに、リードのワークフローをPipelineのワークフローに変換します。重複案件を防ぐ条件（「このコンタクトに関連付けられたオープン案件がない」）が重要です。これがないと、リードステータスが更新されるたびに重複案件が作成されます。

HubSpotでは、「レコードを作成」→ 案件のワークフローアクションを使用し、次に「レコードを関連付け」でコンタクトと企業をリンクします。

Salesforceでは、これはリードがコンバートされたときにOpportunityを作成するFlowまたはプロセスで行います。

オートメーション3：ステージベースのタスク作成

トリガー：案件のPipelineステージが特定のステージに変わる 条件：不要（更新を除外したい場合は案件タイプ = 「新規ビジネス」） アクション：案件オーナーに特定の指示と期日を持つタスクを作成する

案件が「ディスカバリー完了」に入ったとき、次の担当者のアクションは明確であるべきです：フォローアップコールのアジェンダを送る、または技術レビューをスケジュールする。ステージベースのタスク作成は担当者が次に何をすべきかを覚える必要がないことを意味します。CRMが教えてくれます。

案件固有の内容に関わらず一貫した次のステップがあるステージの遷移ごとに1つのタスクワークフローを構築してください。

ステージごとのタスク例：

  • ディスカバリー完了 → タスク：「ディスカバリーサマリーを送付してソリューションデモをスケジュール」（24時間以内）
  • デモ完了 → タスク：「ユースケースドキュメントと価格の概要を含むフォローアップメールを送付」（48時間以内）
  • 提案受諾 → タスク：「契約レビューコールをスケジュールして法務にMSAを送付」（72時間以内）

オートメーション4：期限切れ案件アラート

トリガー：案件の「最終活動日」が X 日以上前で、Pipelineステージがクローズウォンまたはクローズロストでない 条件：案件がアクティブなステージにある（クローズウォン/ロストを明示的に除外） アクション：案件オーナーに高優先度でタスクを作成する：「X日間活動なし — 案件が停滞している可能性あり」

このオートメーションがなければ、停滞した案件はPipelineに静かに居座り予測を膨らませます。マネージャーは案件レビューで発見して担当者に手動で催促します。このオートメーションはPipelineの驚きになる前に問題を浮上させます。

閾値Xはサイクル期間に依存します。30日のSMBサイクルには5日間活動なしでフラグを立てます。90日のエンタープライズサイクルには14日間でフラグを立てます。

オートメーション5：デモ後のフォローアップリマインダー

トリガー：案件のPipelineステージが「デモ完了」（または相当するステージ）に変わる 条件：なし アクション：ステージ変更から24時間後の期日で案件オーナーにタスクを作成する：「デモ後フォローアップ：ユースケースカバレッジを要約し、次のステップを確認し、関連するケーススタディを送付する」

デモ後24時間以内のフォローアップはB2B営業で最も影響力の高いアクションの1つです。購買者はソリューションを見た24時間以内が最も関与度が高いです。その窓内でフォローアップする担当者はより高い確率でコンバートします。しかし手動のフォローアップリマインダーは忘れられます。

オートメーション6：30日間コールドリードの再エンゲージメント

トリガー：コンタクトのプロパティ「リードステータス」= 「オープン」で「最終活動日」が30日以上前 条件：コンタクトがアクティブなシーケンスに登録されていない アクション：コンタクトを「再エンゲージメント」メールシーケンス（2週間で3〜4通のメール）に登録する

静かになったリードは必ずしも死んでいるわけではありません。単に優先順位が下がっただけのことがよくあります。軽い再エンゲージメントシーケンス（重いセールスピッチではなく、「まだXについて考えていますか？」というアプローチ）は、コールドなコンタクトの相当数を再活性化できます。

HubSpotでは：コンタクトベースのワークフローで登録トリガーを使用します。コンタクトが現在アクティブなシーケンスに登録されているかを確認する条件を追加してください。二重登録は避けたいです。

オートメーション7：SlackまたはTeamsへの新規案件通知

トリガー：新しい案件が作成され、Pipelineステージが最初のアクティブステージである 条件：案件金額が閾値以上（オプション — 例えば5万円以上の案件のみ通知） アクション：案件の詳細（案件名、企業、金額、オーナー）を指定されたSlackチャンネルに送る

これは担当者のシステム全体への賛同を得るオートメーションです。担当者は自分の新規案件がSlackで発表されるのを好みます。マネージャーはPipelineが生きていることがわかり喜びます。そして小さなポジティブな強化ループが生まれます：新規案件 = チャンネルでのお祝い。

HubSpotでは：ワークフローでSlackインテグレーションを使用します。アクションは案件プロパティが結合された「Slackメッセージを送信」です。

メッセージはシンプルに保ってください：「新規案件：[企業名] - [案件金額] - オーナー：[担当者名]」。誰もが無視する長文のテキストは避けてください。

オートメーション8：クローズ日変更アラート

トリガー：案件の「クローズ日」プロパティが更新された 条件：案件が以前は今月クローズする予定だったか、クローズ日が2回以上変更された（インクリメントする「クローズ日変更回数」フィールドが必要） アクション：案件オーナーのマネージャーにSlackまたはメールで通知：「[案件名]のクローズ日が変更されました — 新しい日付：[日付]。オーナー：[担当者]。」

クローズ日のズレは予測問題の先行指標です。1回の変更は正常です。2回はパターンです。3回は今四半期中にクローズしない可能性があります。

「クローズ日変更回数」フィールドの構築には追加のオートメーションが1つ必要です：クローズ日が変わったとき、カスタムフィールドの「クローズ日変更回数」を1増やします。次にアラートオートメーションでそのカウンターが2を超えているかどうかを確認します。

オートメーション9：失注タグ付けと失注理由必須化

トリガー：案件のPipelineステージが「クローズロスト」に変わる 条件：「失注理由」フィールドが空欄 アクション：担当者にタスクを送信：「案件がクローズロストになりました — このタスクをクローズする前に失注理由をドキュメントしてください。」フィールドが入力されるまでステージの前進をブロックする（HubSpotではステージ変更時の必須フィールド、SalesforceではバリデーションルールかThrough）。

失注理由データは営業プロセス改善のための最も価値あるインプットの1つです。そして一貫して最も少ないキャプチャです。担当者は案件を失注としてクローズして次に進みます。誰も理由をドキュメント化しません。

このオートメーションは問題を完全には解決しませんが、適切なタイミングに摩擦を生み出します。担当者は失注としてマークするために案件レコードにいます。タスクはすぐに失注理由を要求して表示されます。ほとんどの担当者は記入するでしょう。

オートメーション10：カスタマーサクセスへのOnboardingハンドオフ

トリガー：案件のPipelineステージが「クローズウォン」に変わる 条件：案件タイプ = 「新規ビジネス」（更新や拡張はスキップ） アクション：新しいOnboardingレコード（またはCSプラットフォームのタスク）を作成し、テリトリーまたはアカウントサイズに基づいて適切なCSM担当者に割り当て、SlackでCSチャンネルに通知し、案件をCSオーナーで更新する

このオートメーションは営業とCS間のブリッジです。これがなければ、クローズされた案件はCRMの宙ぶらりんの状態で待機し、営業マネージャーがCSに「これが勝利した」と手動でメールします。これがあると、ハンドオフは自動的、即座、そしてドキュメント化されます。

これがうまく機能するためには：CSのテリトリーまたは割り当てルール（リードルーティングと同じロジック）、CSが新しいアカウントを受け取るためのSlackチャンネルまたはタスクベースのシステム、そして定義されたハンドオフレコード構造（Day 1にCSが必要な情報は何か？）が必要です。

よくある失敗

広すぎるオートメーション。 リード割り当てオートメーションが作成されたすべてのコンタクト（新しいインバウンドリードだけでなく）に発動すると、アクティブな案件の途中で既存のコンタクトを再割り当て始めます。常に条件を追加して適切なレコードにスコープしてください。

通知の過負荷。 10のオートメーションがすべてSlackメッセージを送ると、担当者はSlackを読まなくなります。数時間以内に人間の応答が必要なアクションに通知を予約してください。タスクは1日以内に応答が必要なものに向いています。

パイロット後に誰も無効にしなかったオートメーション。 パイロットチームで全体公開前に実行する場合、テストオートメーションを構築します。作成するすべてのオートメーションをドキュメント化してください。全体公開前に、オートメーションリストを監査して、テストだったものを無効化してください。

トリガーを検証する前に複雑さを構築する。 フルデータベースでオンにする前に、1つのレコードで各オートメーションをテストしてください。HubSpotの登録履歴とSalesforceのデバッグログは、トリガーが正しく発動し、アクションが期待どおりに実行されたかを確認するのに役立ちます。

次のステップ

これらのオートメーションを構築した後、最初の30日間は毎週オートメーションログを監査してください。HubSpotのWorkflow登録履歴とSalesforceのデバッグログには、どのレコードがどのオートメーションをトリガーしたか、アクションが実行されたかどうかが表示されます。予期しない登録、間違ったレコードで発動したアクション、誰も確認しなかった通知を探しています。

30日後、条件を調整し、閾値を修正し、どのオートメーションが望んでいた行動の変化を生み出しているかを確認するのに十分なデータが得られます。

次の主要なステップはフルチームへの展開です。構成済みのCRMからチーム全体が実際に使うものへの移行方法についてはCRM展開と採用ガイドを参照してください。

関連記事