Make.comでHubSpot商談→Slack自動通知 営業チーム連携を高速化
「商談が動いたのに気づくのが翌日」──営業チームでよくあるこの遅れは、HubSpot と Make.com の組み合わせで解消できます。本記事は、HubSpot の商談(ディール)ステージが変わった瞬間に Slack へ自動通知を飛ばし、チーム全員が同じ温度感で動ける状態を作る設計レシピを、編集部の試算とフィルタ設計の注意点を添えて整理した記事です。
- HubSpot の商談(ディール)が動いたら Slack の指定チャンネルに即通知、見落としをゼロに
- 通知トリガーは 新規作成・ステージ変更・受注(クローズ) など目的別に設計できる
- HubSpot 無料プランでも組めるため、追加コストは Make.com の月¥1,400 程度 に収まる
- 通知が多すぎて埋もれる事故を防ぐ フィルタ設計のポイントを明示
- 編集部試算で 月 約4時間の確認・共有作業の圧縮(月5万円規模の人件費相当)に相当
編集長の見解 ── 中小企業の営業現場では、CRM(顧客管理システム)に商談を入力しても「誰がいつ見るか」が決まっておらず、せっかくのデータが活きていないケースが多く見られます。HubSpot を商談の1次データに据え、Make.com が変化を検知して Slack に流す設計にすれば、入力した瞬間にチーム全員へ共有が回ります。本レシピが重視するのは、通知を「全部流す」のではなく 重要な商談だけを選んで届ける フィルタ設計です。通知を意味のある合図として運用できれば、営業会議を待たずにチームが自走します。
なぜHubSpot→Slack自動通知で月4時間が浮くのか
中小企業の営業チームが、商談状況の確認と共有にどれだけ時間を使っているかを分解してみます。編集部が BtoB 営業・士業・制作の小規模チームにヒアリングしてまとめた「典型的な手作業フロー」は次のとおりです。
| 工程 | 月あたり所要(5名チーム) | 内容 |
|---|---|---|
| HubSpot を開いて商談の進捗を確認 | 約80分 | 各自が1日数回ダッシュボードを巡回 |
| 動いた商談を Slack に手で共有 | 約60分 | 「○○社が次フェーズに進みました」と手入力 |
| 受注・失注を関係者に個別連絡 | 約45分 | 担当・上長・バックオフィスへ伝達 |
| 朝会・夕会で進捗を口頭共有 | 約60分 | 既に分かる情報の読み上げ |
| 合計 | 約245分 (≈4.1時間) | — |
HubSpot→Slack自動通知を組むと、1〜3 の工程はほぼ全自動化され、4 の会議も「通知で共有済みの前提」で短縮できます。担当者は確認や転記ではなく「次にどう動くか」の議論に時間を使えるようになり、編集部試算で 月 約4時間の圧縮 に相当します。
時給¥3,000 換算で月¥12,300、5名チームの確認・共有の重複を含めれば月¥50,000 規模の間接コストが、月¥1,400 (Make.com Core) に置き換わる計算です。商談の見落としや共有漏れによる「対応の遅れ」が減ることも、金額に表れない大きな効果です。
続いて、編集部が実装した全体像を ProcessFlow で示します。
完成形のフロー (ProcessFlow)
HubSpot の商談(ディール)が動いたら Make.com が変化を検知し、条件に合う商談だけを整形して Slack の指定チャンネルへ通知する自動化設計
このフローの肝は、ステップ 03 のフィルタです。すべての商談変更を流すとチャンネルが通知で埋もれ、かえって誰も見なくなります。後述するフィルタ設計で「届ける価値のある商談」だけに絞ることが、運用を続けられるかの分かれ目になります。
次に、ゼロから稼働までの具体的な手順を時系列で示します。
設定手順 (TimelineSteps)
amount >= 300000 や dealstage = “受注” など通知条件を設定 → Slack「Create a Message」で対象チャンネルへ投稿。投稿文には会社名・金額・ステージ・担当者・HubSpot のディール URL を差し込みます。最初はテスト用のディールを1件動かして必ず動作検証します。#sales-win)へ祝福メッセージを流す分岐を追加します。Make.com の Router を使い、dealstage = “受注” のときはお祝い文面+金額を、それ以外は通常の進捗通知を出すよう振り分けると、チームの士気と情報整理を両立できます。営業チームの担当者または個人事業主が独力で組める45分手順 (PC操作のみ、コード不要)
ここまでで基本の自動通知は稼働します。次に、運用で最もつまずきやすい「通知設計」について、編集部が現場で見てきた失敗パターンを共有します。
通知設計の失敗パターンと対策
失敗パターン①: 全商談を流して通知が埋もれる ── すべてのディール更新を通知すると、1日に数十件が流れてチャンネルが「通知の壁」になり、誰も読まなくなります。対策は、Make.com の Filter で「金額が一定以上」「特定ステージに進んだとき」だけに絞ること。通知は少なく、確実に読まれる粒度が正解です。
失敗パターン②: メモの更新でも通知が飛ぶ ── 「Watch Deals」はディールの軽微な更新(メモ追記など)でも発火することがあります。意味のある変化だけを拾うには、Filter で「ステージが変わったとき」「金額が入力されたとき」といった条件を明示し、ノイズを除外します。
失敗パターン③: 担当者が分からず宛先が曖昧 ── 通知に担当者名や次のアクションが書かれていないと、「誰が動くのか」が決まらず放置されます。通知文には必ず担当者・金額・次ステージ・HubSpot リンクを含め、Slack のメンション機能で担当者を呼び出す設計にすると対応が早まります。
通知は「数」ではなく「読まれて行動につながるか」で評価します。最初は条件を厳しめに設定し、見落としが出るようなら少しずつ緩める運用が、結果的に長続きします。
次に、自動通知の活用イメージを具体的なシナリオで示します。
中小企業での活用シナリオ
例えば、従業員8名の BtoB 制作会社を想定します。これまでは商談状況を営業担当2名が頭の中で管理し、受注の共有は朝会頼みでした。HubSpot に商談を入力する習慣はあっても、経営者や制作チームがそれを見るのは会議のときだけ。結果として「受注が決まったのに制作の準備が出遅れる」事態が起きていました。
本レシピを導入すると、商談が「提案中」に進んだ時点で #sales チャンネルに通知が飛び、受注が決まれば #sales-win に金額付きで祝福通知が流れます。制作チームは通知を見て事前に段取りを始められ、経営者はダッシュボードを開かずに営業の動きを把握できます。入力する人・見る人・動く人が同じ情報を同時に共有できることが、最大の効果です。
| 導入前 | 導入後 |
|---|---|
| 商談状況は担当者の頭の中、共有は会議頼み | 商談が動いた瞬間に Slack へ自動共有 |
| 受注の連絡が遅れ、後工程が出遅れる | 受注通知で制作・経理が即座に動ける |
| HubSpot を全員が定期巡回(重複作業) | 通知で必要な人に必要な情報だけ届く |
このように、自動通知は「情報を探しにいく営業」から「情報が届く営業」へチームの動き方を変えます。最後に、規約・運用面で気をつけるべき点を整理しておきます。
規約・運用上の注意
HubSpot 無料プランの制限を理解する
HubSpot の CRM は無料で商談(ディール)管理ができますが、レポートや自動化(ワークフロー)など一部機能は有料プランに含まれます。本レシピの「通知の自動化」は Make.com 側で担うため無料プランでも組めますが、HubSpot のネイティブ自動化と役割が重ならないよう、どちらで何を担当するかを決めておくと運用が混乱しません。最新の料金と機能区分は HubSpot 公式の料金ページで確認してください。
Slack の通知設計とチャンネル運用
Slack に大量の自動通知を流すと、ワークスペース全体の体験が悪化します。通知専用チャンネルを用意し、必要なメンバーだけが参加する設計にすると、関係ない人の集中を妨げません。Slack の API 利用やメッセージ投稿には利用規約があるため、大量送信時の制限は事前に確認してください。
Make.com のトークン管理とセキュリティ
Make.com は通信を TLS で暗号化し、接続情報は暗号化保存されます。とはいえ商談情報は取引先名・金額という機密データを扱うため、(1) HubSpot・Slack の接続は最小権限で作成、(2) 担当者の異動・退職時は接続を再認証、(3) Make.com の組織アカウントに2段階認証を設定、の基本運用は徹底してください。
各サービスの利用規約
HubSpot・Slack・Make.com はいずれも商用利用が可能ですが、それぞれの利用規約で連携・利用条件が定められています。API のレート制限や禁止用途は導入前に各社の規約で確認し、無理のない範囲で運用してください。
よくある質問
Q1. Zapier ではなく Make.com を選ぶ理由は？ Make.com は クレジットあたりの単価が安く、Router でのフロー分岐(受注時だけ別チャンネルへ等)の自由度が高い という強みがあります。Zapier は1ステップ1タスク課金のため、条件分岐の多い通知設計ではコストが膨らみがちです。シンプルな1対1通知なら Zapier も選択肢ですが、フィルタや分岐を作り込むなら Make.com が向きます。
Q2. HubSpot の標準機能(ワークフロー)で Slack 通知はできないの？ HubSpot 有料プランのワークフローでも Slack 通知は可能です。ただし通知文の自由な整形や、複数条件での細かい分岐、他ツールとの連携拡張を考えると、Make.com を間に挟む方が後の拡張に強くなります。無料プランで始めたい場合も Make.com 経由が現実的です。
Q3. 通知が多すぎてチームから不満が出たらどうすればいい？ まず Make.com の Filter 条件を厳しくし、「金額が一定以上」「特定ステージに進んだとき」だけに絞ります。それでも多い場合は、進捗通知を1日1回のまとめ配信に切り替える設計も有効です。通知は「数」ではなく「読まれるか」で調整するのが原則です。
Q4. 商談件数が増えたら設計はどう変わりますか？ 件数が増えると、(1) Make.com を Pro プラン以上に切り替え、(2) フィルタをチーム・パイプライン別に細分化、(3) 受注データを Google スプレッドシートや会計ツールへも自動連携、の3点が現実的になります。まずは小さく始めて、運用が定着してから連携先を広げるのが安全です。
出典・参考情報
- Make.com 公式 — 料金プラン (Core / Pro プランの月額とクレジット枠、2026-06-29 アクセス)
- Make.com 公式 — HubSpot CRM 連携 (Watch Deals など利用可能なモジュール)
- Make.com 公式 — Slack 連携 (Create a Message などのアクション)
- HubSpot 公式 — 料金プラン (無料 CRM と有料プランの機能区分)
- Slack 公式 — API ドキュメント (メッセージ投稿の仕様と制限)
関連レシピ
- Make.com で Airtable→Slack 通知を自動化 チームの情報共有レシピ
- Make.com×Google広告×Slack 広告の異常を即検知するレシピ
- Zapier×HubSpot×Gmail でリード対応を自動化する営業レシピ
- Zapier×Pipedrive×Slack で商談進捗をチームに即共有するレシピ
Mira ／ AI経営ラボ 編集長
Make.com を無料で試す → ※ PR・アフィリエイトリンクを含みます