HubSpotとSlack/Teamsをつなぐ目的は、通知を増やすことではありません。CRMへの入力と確認の導線を、社員が毎日開いているチャットの中に置き直すことです。
HubSpotとSlack/Teamsをつなぐ目的は、通知を増やすことではありません。CRMへの入力と確認の導線を、社員が毎日開いているチャットの中に置き直すことです。
ブログ目次
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
HubSpotとSlack/Teamsをつなぐ目的は、通知を増やすことではありません。CRMへの入力と確認の導線を、社員が毎日開いているチャットの中に置き直すことです。
「HubSpotに通知が来ているのに気づかなかった」「Slackで共有された商談情報を、結局HubSpotで検索し直している」「電話が終わった直後は覚えているのに、CRMに入力するのは翌日以降になってしまう」——営業チームやカスタマーサクセスチームがHubSpotとチャットツールを行き来する時間と、その往復の途中で消えていく情報は、意外と馬鹿にならない量になっています。
HubSpot Slack連携とは、HubSpot公式のSlackインテグレーションを使って、CRM上のイベント通知をSlackチャンネルやDMへリアルタイムに配信し、あわせてSlackの会話からHubSpotのレコードを検索・共有・記録できるようにする機能です。Microsoft Teamsにも同様の公式連携があり、どちらも「CRMを開く前に、CRMの情報が届く」状態をつくることが目的になります。
この分野の体系的な情報はHubSpot連携・エコシステムガイドでまとめています。
本記事は「HubSpotのデータ品質管理ガイド|Data Hubで実現するCRMデータクレンジングと運用ルール」シリーズの一部です。
本記事はHubSpotゴールドパートナーのStartLinkの「HubSpot完全ガイド」関連記事です。
連携の設定自体は半日もあれば終わりますが、届け方の設計を誤ると通知はすぐにノイズ化します。この記事では、HubSpotをすでに導入していてCRMとチャットの往復に無駄を感じている方に向けて、設定手順とあわせて「どの通知をどこへ届けるか」の設計の考え方までを順に整理しています。
HubSpotを導入済みで、営業やカスタマーサクセスの現場定着に課題を感じている方、CRMの入力率がなかなか上がらないとお悩みの方に向けて書いています。最後まで読むと、自社のチーム構成に合わせた通知チャンネル設計と、最初に有効化すべき通知を自分で決められるようになります。
チャット連携は「便利そうだから入れる」だけだと、通知ノイズになって終わることがほとんどです。先に、なぜこの連携が必要になるのかという課題の側から整理しておきます。ここを押さえておくと、後の通知設計で何を切り捨てるかの判断がしやすくなります。
この状態が厄介なのは、どれか1つを見ても全体像がわからないことです。Slackで「あの案件どうなってる?」と聞かれた人がHubSpotを開いて確認し、その答えをSlackに書き戻す。しかしその答えはHubSpotには残らないので、次に同じ質問が出たらまた同じ作業が発生します。スプレッドシートで管理していて、Slackに連絡をして、それをまたHubSpotに転記する——この往復が常態化すると、情報は分散する一方です。
逆に、やり取りの起点がCRMレコードになっていれば、過去のやり取りは一覧で確認できます。連携の目的は通知を増やすことではなく、この往復そのものを減らすことにあります。
期待値を先に揃えておきます。この連携で解決できること、できないことは次のとおりです。
| 課題 | チャット連携で解けるか | 補足 |
|---|---|---|
| CRMの更新に気づくのが遅い | 解ける | 通知の即時性が上がる |
| 進捗確認のためのCRM往復が多い | 解ける | スラッシュコマンドで代替 |
| 通話メモの入力が後回しになる | ある程度解ける | Slackから記録できる導線を作る |
| そもそも取引ステージの定義が曖昧 | 解けない | パイプライン設計の課題 |
| 必須項目が入力されていない | 解けない | プロパティ必須化で対応 |
| レポートの数字が信用できない | 解けない | 運用ルールとデータ品質の課題 |
ここは正直に書いておきたいところです。チャット連携は入力と確認の「導線」を改善する施策であって、何を入力すべきかという「設計」の欠落を埋めるものではありません。パイプラインのステージ定義が曖昧なまま通知だけ飛ばしても、流れてくるのは意味の読み取れない更新情報だけになります。取引ステージ・受注確度・ステージ定義・ステージ移行時の必須入力プロパティ、この4つが先に固まっていることが前提になります。
その前提を踏まえたうえで、HubSpotとSlackの連携で実現できることを分類すると、以下の4つに整理できます。
| カテゴリ | できること | 全体フロー上の位置づけ |
|---|---|---|
| 通知 | 取引ステージ変更、フォーム送信、タスク期限などをチャンネルに自動配信 | リード獲得〜商談進行の各節目 |
| 共有 | コンタクト・会社・取引のレコードをチャットに展開 | 部門間の引き渡し・相談 |
| 操作 | スラッシュコマンドやボタンからレコードを検索・記録 | 活動記録のインプット |
| 自動化 | ワークフローのアクションとしてメッセージを送信 | 条件付きのエスカレーション |
コンタクト獲得から取引、顧客化、請求までの一連の流れの中で、チャット連携は「各ステップの節目を知らせる」「そのステップでの活動を記録する」という2つの役割を担います。単体の機能として見るのではなく、この流れのどこに置くかを意識すると設計がぶれません。
ここからは実際の設定に入ります。インストール自体は難しくありませんが、権限の所在と、ユーザー単位の紐づけを忘れると「通知が来ない」の原因になりやすいので、順番どおりに進めるのがおすすめです。
まず、HubSpot側のマーケットプレイスからSlackアプリをインストールします。
インストールにはSlackワークスペースの管理者権限(またはアプリインストール権限)が必要です。Slack側でアプリのインストールが制限されている場合は、Slack管理者にHubSpotアプリの許可を依頼してください。情報システム部門の承認が必要な企業では、ここが一番のリードタイムになることもあります。
続いて、見落とされやすいのがユーザー単位の紐づけです。ワークスペース単位のインストールとは別に、各ユーザーが自分のSlackアカウントをHubSpotに接続する必要があります。これを行わないと、タスクのリマインドなど個人宛の通知がDMで届きません。
管理者が全員分を一括設定できるものではないため、導入時に「各自でここまでやってください」という手順書を配るところまでをセットで考えておくと、後から「自分だけ通知が来ない」という問い合わせを減らせます。
チーム全体に届けたい通知は、Slackの特定チャンネルに送る設定を行います。
ここで「どの通知をどのチャンネルに送るか」の設計が結構ミソになってきます。すべての通知を1つのチャンネルに流すと、情報過多でかえって見逃しが増えるためです。通知の種類や重要度に応じてチャンネルを分けるほうが、結果的に見られる通知になります。
HubSpotからSlackへの通知は、大きく2系統に分かれます。
| 種別 | 主な通知内容 | 届き先 |
|---|---|---|
| 個人通知 | タスクの期限リマインド/自分の担当レコードの更新/担当コンタクトのフォーム送信/メール開封・クリック | Slack DM |
| チーム通知 | 取引のステージ変更/新規フォーム送信/受注・失注/特定アクティビティの追加 | Slackチャンネル |
通知の粒度は細かく設定できます。運用の立ち上げ方としては、最初から完璧を狙うより、チームで実際に必要そうなものだけを有効化し、足りないと感じたら追加していく進め方が現実的です。いきなり全部オンにすると、絞り込む前にチームが通知を見なくなってしまいます。
通知の目的に応じたSlackチャンネル設計の一例です。自社のチーム構成に合わせて増減させてください。
| チャンネル名 | 通知内容 | 対象メンバー |
|---|---|---|
| #sales-deals | 取引のステージ変更、受注/失注通知 | 営業チーム全体 |
| #sales-leads | 新規フォーム送信、新規リード通知 | 営業チーム+マーケティング |
| #cs-tickets | チケット作成、チケットステータス変更 | カスタマーサクセスチーム |
| #marketing-forms | 全フォーム送信の通知 | マーケティングチーム |
| #revenue-wins | 受注のみを通知 | 全社 |
最後の受注通知チャンネルは、業務上の必要性というより文化づくりの意味合いが強いものです。受注の通知が流れるたびにリアクションで祝う習慣ができると、他部門からも自分たちの仕事が売上につながっている実感を持ちやすくなります。ただし、これは全社の人数規模や受注件数によって適不適が分かれます。受注が日に何件も発生する事業では、かえって埋もれるので週次サマリーのほうが向いている、といった具合に、企業様によって最適な形は異なります。
実際に通知が届いたときの見え方も、先にイメージしておくと設計しやすくなります。以下の画面は、検証用に用意したSlackチャンネルに、HubSpotのチケット関連の通知が届いている表示例です。通知はカード形式で流れてくるため、チャンネルごとの通知量を考える際の参考にしてください。

連携のもう半分は、チャットからCRMへの方向です。通知が「CRM→人」の流れだとすれば、こちらは「人→CRM」の流れにあたります。入力率を上げたい場合、実はこちら側のほうが効いてきます。
| やりたいこと | 連携前の動作 | 連携後の動作 |
|---|---|---|
| 取引の進捗を確認する | ブラウザでHubSpotにログインして検索 | Slackでスラッシュコマンドを実行 |
| 通話・商談のメモを残す | レコードを開いてアクティビティを入力 | レコードカードのボタンから記録 |
| 案件をチームに相談する | 画面を撮影してチャットに貼る | レコードをカード形式で共有 |
Slack連携をインストールすると、Slack上でスラッシュコマンドが使えるようになります。
/hubspot [検索キーワード]:コンタクト、会社、取引をキーワード検索/hubspot-contact [名前またはメール]:コンタクトを検索/hubspot-company [会社名]:会社を検索/hubspot-deal [取引名]:取引を検索検索結果はSlack上にカード形式で表示され、名前、メールアドレス、電話番号、取引金額、ステージなどの主要プロパティをその場で確認できます。カードには「HubSpotで開く」リンクも付いているため、詳細が必要ならワンクリックでCRMに移動できます。
会議中に「あの顧客の直近の取引ステージどうなってたっけ?」と聞かれたとき、ブラウザを開いてHubSpotにログインして検索する——という一連の動作が、コマンド1行に置き換わります。1回あたりの短縮時間は小さいものの、毎日発生する動作なので積み上がります。
逆方向、HubSpotの画面からSlackにレコードを共有することもできます。
共有されたレコードはSlack上にカード形式で表示されます。これまでスクリーンショットを貼ったり、「○○社の件、現在見積提出段階です」と手打ちしていた報告が、ワンアクションで正確な情報として共有できるようになります。
ここで地味に大きいのは、共有された情報が常にCRMの最新状態を指している点です。手打ちの報告はその瞬間のスナップショットでしかなく、翌日には古くなります。
Slack上に表示されたHubSpotレコードのカードには、クイックアクションボタンが付いています。
これは仕組み化の観点で重要な機能です。営業の入力漏れは、本人の意識の問題として語られがちですが、実際には入力の導線が業務の流れから外れていることが原因になっているケースが多くあります。電話を終えた直後、まだSlackを開いている状態でそのままメモを残せるなら、「後でCRMに入力しよう」と思って忘れる確率は下がります。
マネジメント側としては、「CRMにちゃんと入力して」と言い続けるよりも、入力の導線を普段使いのツールに統合するほうが、担当者が変わっても同じ運用が回ります。人の意識ではなく仕組みで解決する、という発想です。
標準の通知設定は「イベントが起きたら知らせる」までですが、HubSpotのワークフローを使うと「どういう条件のときに、誰に、何を知らせるか」まで踏み込めます。自社の業務プロセスに合わせた通知を組むならこちらです。
ワークフローのアクションに「Slack通知を送信」が用意されており、以下を設定できます。
以下の画面はHubSpotのワークフローエディタで、左側のトリガー条件に続けて通知アクションを配置していく構成になっています。
初めてワークフローを組む方は、いきなり複雑な分岐を設計しようとせず、まず1本の単純な通知から作ってみて、後から条件を足していくほうが挫折しにくいかなと思います。
代表的な設計パターンを、トリガーと通知先の組み合わせで整理します。
| パターン | トリガー条件 | 通知先 | 狙い |
|---|---|---|---|
| 大型案件アラート | 一定金額以上の取引が「提案中」に移行 | アラート専用チャンネル | マネージャーの早期関与 |
| リード即時フォロー | 特定フォームの送信 | チームチャンネル+担当者DM | 初回接触までの時間短縮 |
| チケットエスカレーション | 高優先度のまま一定時間未対応 | CS管理チャンネル | 対応漏れの検知 |
| 定期サマリー | スケジュール(月初など) | 営業マネジメントチャンネル | 数値の定点共有 |
| 顧客の行動シグナル | 既存顧客が料金ページを閲覧 | 担当CSのDM | アップセル/解約リスクの察知 |
金額や時間のしきい値は、自社の平均受注単価やSLAの水準から逆算して決めるものです。ここを他社の数値で決めてしまうと、アラートが多すぎるか、まったく鳴らないかのどちらかになります。まずは自社の取引データを分布で眺めて、「マネージャーが把握しておきたいのは上位何件か」という観点で置いてみるのがよいかと思います。
パターンの中でも、最初に組んでみると効果が見えやすいのが大型案件アラートとリード即時フォローの2本です。
大型案件アラートは次の順序で組み立てます。
ポイントは、通常の取引通知チャンネルとは分けることです。同じチャンネルに混ぜると、日常の更新通知に埋もれてアラートの意味がなくなります。「このチャンネルが鳴ったら見る」という状態を維持できる分量に抑えるのが設計の要点です。
リード即時フォローは、問い合わせ対応のスピードを仕組みに変えるパターンです。担当者が気づくかどうかという属人的な要素に左右されがちな部分を、ワークフローで置き換えます。
DMのメッセージに「◯分以内に初回コンタクトしてください」と対応期限を書き込んでおくと、何をいつまでにやるかが通知の中で完結します。新しく入ったメンバーでも、通知の指示どおりに動けば一定の品質で対応できる状態になります。これが仕組み化の効果で、対応スピードが個人の習慣に依存しなくなります。
同じ発想を広げると、ワークフロー×Slack通知で簡易的なSLA(サービスレベルアグリーメント)管理も組めます。
| 対象プロセス | SLAの例 | 超過時のアクション |
|---|---|---|
| リード発生→初回コンタクト | 短時間での初回接触 | 担当者DM+未対応ならマネージャーへ |
| チケット受付→初回回答 | 当日中の一次回答 | CS管理チャンネルにエスカレーション |
| 見積依頼→見積提出 | 翌営業日までの提出 | 営業マネージャーに通知 |
具体的な時間の基準は、自社の商材の検討速度と体制で決まります。専用のSLA管理ツールを導入しなくても、HubSpotとチャット連携の組み合わせで最低限のモニタリングは成立します。ただし、超過件数の集計や傾向分析まで求めるなら、レポート側の設計が別途必要になります。
Teamsを主要なコミュニケーション基盤にしている企業も多いので、こちらも整理しておきます。HubSpotはMicrosoft Teamsとも公式連携を提供しており、基本的な考え方はSlack連携と同じです。
Teams連携で利用できる主な機能は以下のとおりです。
Microsoft 365を全社基盤にしている企業であれば、会議の記録がCRMに自動で残る点は特に効いてきます。
設定手順は次のとおりです。
企業によってはTeams管理センター側でサードパーティアプリが制限されているため、Slackと同様に情報システム部門との調整が先に必要になることがあります。
なお、HubSpotとMicrosoft系ツールの接点はTeamsの通知連携だけではありません。以下の画面は、HubSpotのAIアシスタント「Breeze」向けに用意されている連携アプリの一覧で、Teamsのほかにも連携アプリが並んでいます。先ほど挙げたTeams会議の自動記録のように、Microsoft 365を全社基盤にしている企業では、チャット通知以外にも連携の選択肢があります。

| 項目 | Slack連携 | Teams連携 |
|---|---|---|
| スラッシュコマンド | あり(/hubspot) | なし(メッセージングエクステンションで代替) |
| レコード共有 | リッチカード形式 | アダプティブカード形式 |
| クイックアクション | タスク作成、メモ追加、コール記録 | タスク作成、メモ追加 |
| ワークフロー連携 | あり | あり |
| 会議連携 | Zoom連携等と組み合わせ | Teams会議の自動記録 |
| Bot機能 | HubSpot Bot(チャットフロー) | HubSpot Bot(制限あり) |
操作系の機能はSlack連携のほうがやや豊富ですが、これは「Slackを選ぶべき」という意味ではありません。連携先は、営業チームが実際に一日中開いているツールに合わせるのが原則です。機能が多いという理由でSlackを選んでも、チームがTeamsで会話しているなら通知は見られません。両方を併用している企業では、部門ごとにメインツールが違うケースもあるため、通知の届き先をどちらに寄せるかを先に決めてから設定に入るのがおすすめです。
なお、チャットツールとCRMをつなぐという考え方自体は、HubSpot固有のものではありません。リレーショナルデータベースを持つCRMであれば同様の連携は実現できますし、他のCRMから移行された方であれば同じ発想の仕組みを見たことがあるかもしれません。ここで整理した「通知の設計」の考え方は、ツールが変わっても使い回せる部分です。
設定が終わった直後は全員が通知を見ます。問題はその3か月後です。連携が形骸化する原因はほぼ通知の設計にあるので、運用側の考え方を整理しておきます。私たちは通知設計を「届く・埋もれない・次の行動につながる」の3段で考えることをおすすめしています。
Slack連携で特にありがちな失敗は、通知が多すぎて全部が無視されるようになるパターンです。優先度で階層を分けるのが基本になります。
| 優先度 | 該当する通知 | 届け方 |
|---|---|---|
| 高(即時対応) | 新規リードの問い合わせ、大型案件のステージ変更、チケットのエスカレーション | 専用チャンネル+メンション |
| 中(当日中に確認) | 一般的な取引ステージ変更、タスク期限のリマインド | チーム通知チャンネル |
| 低(参考情報) | メール開封通知、Webサイト閲覧通知 | 個人DM(必要な人のみ有効化) |
低優先度の通知チャンネルは、Slack側でミュート(デスクトップ通知オフ、未読バッジオフ)にしておき、手が空いたときにまとめて確認するスタイルにしておくと、高優先度の通知が埋もれません。
プロパティ設計と同じ話ですが、通知も数が少ないほうが集中できます。SFAで使っていない項目が大量に並んでいる状態と、誰も読まない通知チャンネルが並んでいる状態は、本質的に同じ問題です。
四半期に一度、「この3か月で一度もアクションにつながらなかった通知」を洗い出してオフにする、といった棚卸しの機会を設けておくと、通知の鮮度を保てます。追加は簡単で削除は後回しにされがちなので、削除の機会をカレンダーに組み込んでおくのが現実的です。
通知の話に隠れがちですが、レコード共有は部門間連携の質を変えます。
テキストの口頭報告ではなく、CRMレコードという事実ベースの情報を起点にすると、議論が「印象」ではなく「データ」の上で進みます。特に部門をまたぐ相談では、前提のすり合わせにかかる時間が減ります。
正直なところ、すべての組織にとって効果が大きい施策ではありません。次のようなケースでは、優先度を下げて他の整備を先に進めるほうがよいかと思います。
| 状況 | 理由 |
|---|---|
| 取引ステージの定義が社内で揃っていない | 通知の内容が読み手ごとに違う意味になる |
| CRMにそもそも取引が登録されていない | 通知するイベント自体が発生しない |
| チャットツールが組織に定着していない | 通知の到達率が上がらない |
| 少人数で全員が同じ案件を把握している | 共有コストがもともと低く、効果が薄い |
こうした場合は、パイプライン設計やプロパティの必須化といった土台の整備を先に済ませてから、チャット連携に戻ってくるほうが結果的に早く回ります。
設定後によくある詰まりどころを整理します。ほとんどは権限か紐づけの問題なので、切り分けの順番を持っておくと解決が早くなります。
「一部の人だけ届かない」場合はユーザー紐づけ、「全員届かない」場合はアプリ権限かチャンネル設定、という切り分けが基本になります。
| 症状 | 確認ポイント |
|---|---|
| スラッシュコマンドが反応しない | アプリがそのワークスペースにインストールされているか/Slack管理者がコマンドを制限していないか |
| ワークフローの通知が送信されない | ワークフローが有効になっているか/指定チャンネルが存在するか/トリガー条件を満たすレコードがあるか |
| 通知が重複して届く | 標準通知設定とワークフロー通知の重複/同一イベントに複数のワークフローが設定されていないか |
特に通知の重複は、運用しているうちにワークフローが増えて起きやすくなります。新しい通知ワークフローを作る前に、既存のワークフロー一覧を確認する習慣をつけておくと防げます。
Slack連携アプリのインストールと基本的な通知機能は無料プランでも利用できます。ただし、ワークフローからのSlack通知送信はMarketing Hub、Sales Hub、Service HubのいずれかのProfessional以上が必要になります。無料プランの範囲では、標準通知のSlack配信とスラッシュコマンドによるレコード検索が中心となり、この記事のワークフロー設計パターンは対象外になります。
両方と同時に連携できます。ただし、同じ通知を両方に流すと冗長になり、どちらも見られなくなるおそれがあります。部門ごとに主に使っているツールが異なる場合は、「営業チームはSlack、カスタマーサポートはTeams」のように通知の届き先を分ける設計も選択肢になります。まずはどちらか一方で運用を確立してから広げるほうが、設定の重複を避けやすいかと思います。
送信できます。ただしプライベートチャンネルの場合は、HubSpot Botを手動でチャンネルに招待する必要があります。チャンネル内で/invite @HubSpotと入力するか、チャンネル設定からHubSpotアプリをメンバーに追加してください。通知が届かない原因として特に多いのがこの招待漏れです。
メッセージ内で@ユーザー名のメンション記法を使用できます。@channelや@hereといったグループメンションも利用可能です。HubSpotのパーソナライゼーショントークンと組み合わせれば、取引の所有者に動的にメンションするといった設計もできます。ただし、グループメンションを多用すると通知疲れを招くため、優先度の高い通知に限定するのが無難です。
Slackの会話そのものは自動記録されません。記録されるのは、Slack上のカードから「メモを追加」「タスクを作成」などのクイックアクションを実行した内容です。会話の文脈をCRMに残したい場合は、要点を手動でメモとして追加する運用を決めておく必要があります。ここは連携の限界なので、「Slackの会話も自動でCRMに残る」と期待して導入すると評価がずれます。
チャット連携の価値は、通知の数ではなく、CRMへの入力と確認の導線が業務の流れの中に入ることにあります。要点を整理します。
最初の一歩としては、まず標準のSlack通知を1チャンネルだけ設定するところから始めてみてください。そのうえで、次の3ステップで広げていくのがおすすめです。
企業様によって最適な通知設計は異なりますので、自社の商談件数・チーム人数・商材の検討速度を踏まえて調整いただければと思います。
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化(ERP/CRM/SFA/MAの導入)」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
株式会社StartLink 代表取締役。累計150社以上のHubSpotプロジェクト支援実績を持ち、Claude CodeやHubSpotを軸にしたAI活用支援・経営基盤AXのコンサルティング事業を展開。
HubSpotのトップパートナー企業や大手人材グループにて、エンタープライズCRM戦略策定・AI戦略ディレクションを経験した後、StartLinkを創業。現在はCRM×AIエージェントによる経営管理支援を専門とする。