%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
HubSpotとAsanaの連携は、営業からデリバリーへの引き継ぎを担当者の記憶ではなく仕組みで回すための設計です。顧客のマスターデータはHubSpot、プロジェクトの実行管理はAsanaに分ける。
HubSpotとAsanaの連携は、営業からデリバリーへの引き継ぎを担当者の記憶ではなく仕組みで回すための設計です。顧客のマスターデータはHubSpot、プロジェクトの実行管理はAsanaに分ける。
「営業が受注した後のプロジェクト進行が見えず、納品遅延が発生している」「CRM上では受注済みなのに、タスク管理が別ツールで情報が分断されている」——こうした課題は、HubSpotとAsanaの連携で解消に向かいます。
HubSpot × Asana連携とは、CRM上の取引（商談）情報をきっかけにAsanaのプロジェクトやタスクを作成し、受注後のデリバリー進捗をHubSpotから参照できるようにする仕組みです。Asanaはタスク・プロジェクト管理に特化したツールで、チームの作業進捗を可視化するのに優れています。
この記事では、HubSpot × Asana連携のメリットから設定方法、活用設計、運用上の限界まで解説します。
本記事は「HubSpot購入グループ（Buying Groups）活用ガイド｜ABM戦略を加速する設計」シリーズの一部です。
本記事はStartLinkの「HubSpot完全ガイド」関連記事です。
この記事でわかること
HubSpot・営業・CRMの取り組みを検討されている方に向けて、営業とデリバリーをつなぐ連携の考え方と、設定から運用までの進め方をまとめています。
- HubSpot × Asana連携の全体像とメリット — 取引をきっかけにAsanaのプロジェクトを作り、デリバリーの進捗をCRMから参照する仕組みと、その効果を整理します。
- 3通りの設定方法と選び方 — 公式アプリ、Yoom・Zapierなどのノーコード連携、ワークフローとAsana APIの組み合わせを比較します。
- 受注→デリバリーの統合フロー設計 — パイプラインのどのステージでAsanaを動かすか、テンプレートをどう組むかを具体的に示します。
- CRM側とプロジェクト管理側の役割分担 — 二重管理を防ぐために、どの情報をどちらに持たせるかを表で整理します。
- 運用上の注意点と限界 — 連携を広げすぎたときの問題や、APIの実行制限など、導入前に知っておきたい制約をお伝えします。
HubSpot × Asana連携とは？スプレッドシートでの引き継ぎから抜け出す考え方
多くの企業では、営業はHubSpot、プロジェクト管理はAsanaと、別々のツールで運用されています。
2つのツールの間をスプレッドシートの引き継ぎ表やチャット、口頭でつないでいると、受注した瞬間に情報が途切れやすくなります。この節では、分断によって何が起きるのかと、連携で何が変わるのかを整理します。
受注の瞬間に情報が途切れる理由
営業は商談の経緯や顧客の要望を取引レコードに残し、デリバリーチームはAsanaでタスクを進めます。この2つをつなぐ役割を、スプレッドシートの引き継ぎ表が担っているケースは少なくありません。
引き継ぎ表を使う運用では、営業が取引レコードの内容を手で転記し、デリバリー側がそれを見てAsanaにプロジェクトを作ります。
転記のたびに差分が生まれ、どちらが正しい情報なのかがわからなくなっていきます。
その結果として、次のような問題が起きます。
- 「営業は受注したが、デリバリーチームに情報が正確に伝わっていない」
- 「プロジェクトの遅延が営業側で把握できない」
こうした問題は、担当者の注意力が足りないから起きるのではなく、情報の置き場所が分かれている構造から生まれます。
だからこそ、人に頑張ってもらうよりも、ツール同士をつないで構造そのものを変える方が効果的だと考えています。
連携前と連携後の違い
連携によって変わるのは、受注後の各場面で「誰が何を見て動くか」です。代表的な場面を比べると、次のようになります。
| 場面 | 連携前（スプレッドシート・口頭） | 連携後（HubSpot × Asana） |
|---|---|---|
| 受注後の引き継ぎ | 営業がチャットやメールで依頼し、デリバリー側が手でプロジェクトを作る | 取引ステージの変更をきっかけにAsanaへプロジェクトが作られる |
| 顧客情報の共有 | 引き継ぎ表に転記し、更新のたびに差分が生まれる | Asanaのプロジェクトから取引レコードへのリンクで参照する |
| 進捗の把握 | 営業がデリバリー担当に聞きに行く | 取引レコードで主要マイルストーンの状況を見る |
| 遅延への気づき | 顧客からの問い合わせで初めて気づく | 期限超過を取引担当者へ通知する |
全体フローの中での位置づけ
HubSpotでは、コンタクト・会社・取引が互いに関連付けられ、リードの獲得から商談、受注、請求までの流れを1つのデータベースで追えます。
Asana連携は、この流れのうち「取引が受注に進んでから、請求・更新に至るまで」の区間を埋める役割を持ちます。
営業活動の記録がHubSpotにあり、デリバリーの進捗もHubSpotから参照できれば、担当者が変わっても過去のやり取りとプロジェクトの状況を一覧で追えます。
Asana連携を単体の便利機能として捉えるのではなく、受注前後をつなぐ部品として全体フローの中に置くことが、設計の出発点になります。
HubSpot × Asana連携で得られる3つのメリット
連携のメリットは、次の3つに整理できます。
- 引き継ぎの自動化
- 営業によるデリバリー状況の把握
- 顧客データの一元管理
いずれも、営業とデリバリーが同じ顧客を別々の画面で見ている状態を解消することから生まれます。順番に見ていきます。
1. 受注→デリバリーの引き継ぎが自動化される
取引が所定のステージに移行したタイミングで、Asanaにプロジェクトが作成され、必要なタスクがテンプレートから展開されます。
営業からデリバリーチームへの情報伝達が仕組みとして自動化されるため、口頭やメールでの引き継ぎ漏れを防げます。
引き継ぎの品質が担当者の経験に左右されなくなる点も大きな効果です。新しく入った営業でも、取引ステージを進めるだけでデリバリー側に同じ形式の依頼が届きます。
営業活動の属人化を解消する方法論についてはCRM/SFA活用によるパイプライン管理も参考になります。
2. 営業がデリバリー状況を把握できる
HubSpotの取引レコードからAsanaのプロジェクト進捗を参照できるようになるため、営業が顧客から「プロジェクトの進捗はどうなっていますか？」と聞かれた際に、すぐに回答できます。
デリバリー担当に都度確認する手間が減るだけでなく、遅れの兆しを営業が早めに知れるようになります。顧客への説明を先回りできれば、関係の悪化を防ぎやすくなります。
3. 顧客データの一元管理が維持される
Asanaのプロジェクト情報がHubSpotのCRMデータと紐づくことで、顧客に関する情報（営業履歴、契約内容、プロジェクト進捗、サポートチケット）がCRMを起点に参照可能になります。
経営やマネージャーの立場から見ると、受注後の状況まで含めて顧客ごとの全体像を追えることが価値になります。HubSpot × Notion連携を組み合わせれば、ナレッジ管理までCRMに統合できます。
HubSpot × Asana連携の設定方法は3通り
連携の方法は、公式アプリ、iPaaS（ノーコードでツール同士をつなぐサービス）、ワークフローとAsana APIの組み合わせの3通りです。
自動化の範囲が広がるほど、設定と保守の手間も増えていきます。まず方法ごとの手順を示し、最後に選び方を表で整理します。
方法1: HubSpot公式Asanaアプリ
HubSpotのマーケットプレイスで「Asana」を検索し、公式アプリをインストールします。手順は次のとおりです。
- HubSpotマーケットプレイスで「Asana」を検索・インストールする
- Asanaアカウントの認証を行う
- HubSpotの取引レコードからAsanaのタスクを作成できる状態にする
- Asanaのタスク進捗がHubSpotのタイムラインに表示されることを、テスト用の取引で試す
テスト用の取引でタスクを作り、タイムラインに進捗が表示されれば、基本連携の準備は整っています。
表示されない場合は、認証したAsanaアカウントが対象のワークスペースに参加しているかどうかから見直すと、原因を切り分けやすくなります。
方法2: Yoom・Zapierを使った高度な自動化
公式アプリの基本連携に加えて、iPaaSツールを使うことで、より高度な自動化が実現できます。代表的な自動化の例は次のとおりです。
- 取引ステージが契約締結に変更されたら、Asanaにプロジェクトをテンプレートから自動作成する
- Asanaのマイルストーンが完了したら、HubSpotの取引プロパティに進捗を自動記録する
- Asanaのタスクが期限超過になったら、HubSpotの取引担当者にアラートを送る
ノーコードの連携フローを選ぶ場合は、更新する取引と作成するAsanaプロジェクトの対応を先に決めます。設定の流れはHubSpot × Yoom / Make連携で解説しています。
方法3: HubSpotワークフロー＋Asana API
HubSpotのワークフロー内でカスタムコードアクションを使い、AsanaのAPIを呼び出して連携を構築する方法です。
取引の複数のプロパティを組み合わせてテンプレートを選ぶなど、ノーコードでは表現しにくい条件分岐も書けます。カスタムコードアクションには、次の制約があります。
- 対象プラン ── Data Hub ProfessionalまたはEnterpriseで利用できる機能です
- 実行時間 ── 1回の実行は20秒以内です
- メモリ ── 128MBまでです（出典：Custom code workflow actions）
1つのアクションで大量のタスクを一度に作る処理は、この制限にかかりやすくなります。
- プロジェクトの作成とタスクの展開 ── Asana側のテンプレート機能に任せます
- コード ── テンプレートを呼び出すだけにしておくと、実行時間を短く保てます
ワークフローの基本はHubSpotワークフロー設計ガイドをご覧ください。
3つの方法の選び方
どの方法を選ぶかは、「何を自動化したいか」と「誰が保守するか」の2点で決まります。
| 方法 | 向いているケース・向かないケース | 保守の担い手 |
|---|---|---|
| 公式アプリ | 向いている：取引レコードからタスクを作り、進捗をタイムラインで見られれば十分な場合 向かない：ステージ変更をきっかけにプロジェクトを自動作成したい場合 |
HubSpot管理者 |
| Yoom・Zapier | 向いている：ステージ連動の自動作成や期限超過の通知まで、ノーコードで組みたい場合 向かない：条件分岐が多く、フローが読み解けなくなる場合 |
業務部門の担当者 |
| ワークフロー＋Asana API | 向いている：独自の条件でテンプレートを切り替えるなど、細かな制御が要る場合 向かない：社内にコードを保守できる人がいない場合 |
エンジニア |
判断に迷ったら、まず公式アプリで取引とタスクをつなぎ、自動作成が欲しくなった段階でiPaaSを加える順番をおすすめします。
受注からデリバリーまでの統合フロー設計
連携の効果は、パイプラインのどのステージでAsanaを動かすかによって大きく変わります。営業の取引ステージとデリバリーのプロジェクト工程を、1本の流れとして設計することがポイントになってきます。
この節では、全体フロー、ステージとの連動、引き継ぎ情報の揃え方を順に説明します。
全体フローを1本の流れで描く
受注前後の流れを、HubSpot側とAsana側に分けて並べると次のようになります。
| 順番 | HubSpot（CRM）側 | Asana（プロジェクト管理）側 |
|---|---|---|
| 1 | 営業活動・見積もり提示 | （動きなし） |
| 2 | 受注・契約締結（ステージ変更） | プロジェクト自動作成・キックオフタスク |
| 3 | デリバリー中のステータス参照 | 要件定義・実装のタスク進行 |
| 4 | 検収完了・請求 | 納品・検収タスクの完了 |
| 5 | 更新・アップセルの検討 | プロジェクトからのフィードバック共有 |
最後の段階で、デリバリーで得た気づきを営業側に戻す流れを作っておくと、更新やアップセルの提案につながります。受注で終わらせず、次の商談の起点まで含めて描くのが一気通貫の設計です。
パイプラインとAsanaの連動設計
取引ステージごとに、Asana側で何を起こすかを決めておきます。
| HubSpotステージ | Asana側のアクション |
|---|---|
| 受注内示 | （まだAsanaプロジェクトは作成しない） |
| 契約締結 | Asanaにプロジェクト自動作成＋キックオフタスク生成 |
| デリバリー中 | Asanaのプロジェクト進捗に連動してHubSpotを更新 |
| 検収完了 | Asanaの全タスク完了をきっかけにHubSpotのステージを更新 |
| 請求 | HubSpotの請求フローに移行 |
ここが要点になるのですが、Asanaのプロジェクト作成タイミングは「契約締結」以降にするのがおすすめです。
「受注内示」の段階でプロジェクトを作ると、最終的に契約が成立しなかった場合に空のプロジェクトが残ってしまいます。
デリバリーの準備を早めに始めたい場合は、受注内示の時点ではAsanaを動かさず、HubSpot上でデリバリー責任者へ通知するタスクを作るだけに留める方法もあります。
ステージ定義と必須プロパティで引き継ぎ情報を揃える
自動作成されたプロジェクトが役に立つかどうかは、取引レコードにどれだけ正確な情報が入っているかで決まります。
そこで、パイプライン設計の考え方である「ステージ定義」と「必須入力プロパティ」を、引き継ぎの品質を保つ仕組みとして使います。具体的には、次のようにします。
- 契約締結ステージの定義を「契約書の締結が完了し、デリバリーの開始条件が揃った状態」のように社内で言葉にしておきます
- そのうえで、契約締結ステージへ移るときに、デリバリーの開始時に欠かせない項目（契約開始日、提供範囲、顧客側の窓口担当者など）を必須入力にします
項目が空のままではステージを進められないため、情報不足のままプロジェクトが作られる事態を防げます。必須項目は、デリバリー側が最初のキックオフで困る情報だけに絞ってください。
- 使われない項目が増えると ── 営業が入力を面倒に感じ、形だけの値が入るようになります
- 必須入力の項目 ── 新しく入った営業が「受注時に何を確認しておくべきか」を学ぶ手がかりにもなります
次の画面は、HubSpotの取引レコード詳細画面の例です。引き継ぎに使う情報をこのレコードに集めておき、Asanaのプロジェクトからリンクで参照できるようにしておくと、転記の手間がなくなります。
Asanaのプロジェクトテンプレート設計
契約締結で自動展開するプロジェクトは、Asana側のテンプレートとしてあらかじめ用意しておきます。テンプレートの出来が、デリバリーの立ち上がりの速さを左右します。
ここでは、基本構成、HubSpotから引き継ぐ情報、案件特性に合わせた調整の3点を説明します。
テンプレートの基本構成
受注時に自動展開するテンプレートの構成例は次のとおりです。各フェーズの期日は、自社の標準的な進行期間に合わせて設定してください。
- キックオフ準備
- キックオフ日程調整
- 顧客情報の共有（HubSpotの取引レコードリンク）
- プロジェクト計画書の作成
- 要件定義
- 要件ヒアリング
- 要件定義書の作成
- 顧客レビュー
- 実装・設計
- 設計ドキュメント作成
- 実装作業
- 内部レビュー
- 納品・検収
- テスト実施
- 顧客トレーニング
- 検収確認
フェーズの区切りをマイルストーンとしてAsanaに設定しておくと、後の段階で「マイルストーン完了をHubSpotに記録する」連携を組みやすくなります。
HubSpotから引き継ぐ情報の決め方
Asanaのプロジェクトに書き込む情報は、次の程度に留めることをおすすめします。
- 取引レコードへのリンク
- 顧客名
- 契約開始日
- 提供範囲
顧客の連絡先や過去の商談履歴まですべてAsanaへ複製すると、HubSpot側で情報が更新されたときに、Asana側だけ古い情報が残ってしまいます。
判断の基準は「その情報がデリバリーの作業中に頻繁に参照されるか」です。
- 頻繁に参照するもの ── Asanaのプロジェクト説明に書き込みます
- ときどき見る程度のもの ── 取引レコードへのリンクから辿ってもらう形にすると、二重管理を避けられます
案件の特性に合わせてテンプレートを分ける
提供するサービスの種類によって、デリバリーの工程は変わります。例えば、コンサルティングの案件と制作の案件では、要件定義に時間をかける度合いも、顧客トレーニングの有無も異なります。
その場合は、取引に「案件種別」のようなプロパティを持たせ、値ごとに呼び出すAsanaテンプレートを切り替える設計が有効です。
ただし、テンプレートの種類を細かく分けすぎると、テンプレート自体の保守が負担になります。
まずは最も件数の多い案件種別で1つのテンプレートを運用し、工程の違いが繰り返し問題になった種別から分けていく進め方が現実的だと考えています。
HubSpotとAsanaの役割分担
連携がうまくいかない原因の多くは、2つのツールの役割が曖昧なまま同じ情報を両方で管理してしまうことにあります。
どの情報をどちらのツールで「正」とするかを先に決めておくと、連携の設計もシンプルになります。この節では、分担表と、営業タスクの扱い、仕組み化の考え方を整理します。
管理項目ごとの分担表
管理項目ごとに、メインで管理するツールと参照するだけのツールを分けます。
| 管理項目 | HubSpot（CRM） | Asana（PM） |
|---|---|---|
| 顧客情報 | マスター管理 | 参照のみ |
| 商談管理 | メイン | 関連リンクのみ |
| 契約情報 | メイン | 参照のみ |
| プロジェクト進捗 | ステータス参照 | メイン管理 |
| タスク管理 | 営業タスクのみ | デリバリータスク |
| レポート | 営業KPI | プロジェクトKPI |
マスターデータはHubSpotに持ち、プロジェクトの実行管理はAsanaで行う——この役割分担を明確にしておくことが、情報の二重管理を防ぐ鍵です。
営業タスクはHubSpotに残す
架電、メール送信、資料作成といった営業活動のタスクは、HubSpotのタスク機能で管理する方が効率的です。CRMの顧客情報と直結しているため、画面を行き来する手間が少なく済みます。
Asanaはデリバリー・プロジェクト管理に特化させ、営業タスクと混ぜないようにしておくと、どちらのツールを開けば何がわかるかがはっきりします。
- 営業マネージャー ── HubSpotのレポートで営業KPIを見ます
- デリバリーの責任者 ── Asanaでプロジェクトを見ます
引き継ぎを人に頼らない仕組みにする
引き継ぎの品質を人に頼っていると、経験豊富な営業が異動したり退職したりした途端に、デリバリーの立ち上がりが遅くなります。
次の形にしておけば、誰が担当しても同じ水準の引き継ぎになります。
- ステージ変更でプロジェクトが作られる
- 必須項目がそろっていないとステージを進められない
さらに、引き継ぎのルールを取引ステージの定義として文章で残しておくと、新しく入ったメンバーへの説明もその定義を見せるだけで済みます。
ツールの設定と社内ルールを一致させておくことが、運用を定着させるうえでのポイントになってきます。
スモールスタートで段階的に広げる進め方
連携でやりたいことをすべて一度に実装しようとすると、設定が複雑になり、どこで不具合が起きているのかも追いにくくなります。
効果が出やすいところから始め、各段階で運用が定着してから次へ進むのがおすすめです。段階ごとの内容と、次へ進む目安は次のとおりです。
| 段階 | 連携する内容 | 次へ進む目安 |
|---|---|---|
| 第1段階 | 契約締結時のプロジェクト自動作成 | 契約締結した取引すべてにAsanaプロジェクトが作られ、手作業での作成がなくなっている |
| 第2段階 | 主要マイルストーンのステータス連携 | 営業がデリバリー担当に進捗を聞きに行く場面がほぼなくなっている |
| 第3段階 | 期限超過アラートと更新・アップセルへの接続 | 通知を受けた担当者が、その日のうちに次の行動を決められている |
第1段階：契約締結時のプロジェクト自動作成
最初は「契約締結でプロジェクトが自動作成される」ことだけを実現します。この段階で、次の3つを整えておくと、後の段階がスムーズになります。
- 取引ステージの定義
- 必須項目
- Asanaのテンプレート
運用を始めたら、契約締結した取引の一覧とAsanaのプロジェクト一覧を並べて、作られていないプロジェクトがないかを定期的に見比べてください。
漏れがなくなり、デリバリー側が手でプロジェクトを作ることがなくなった時点が、第2段階へ進む目安です。
第2段階：主要マイルストーンのステータス連携
次に、Asanaのマイルストーン完了をHubSpotの取引プロパティへ記録する連携を加えます。連携するのは、要件定義の完了、納品、検収といった顧客への報告に使う節目だけに絞ります。
個々のタスクの完了まで連携すると、取引レコードの更新履歴が細かくなりすぎて、営業にとって読みにくくなります。営業が顧客に説明するときに使う粒度で連携する、と決めておくと迷いません。
第3段階：期限超過アラートと更新・アップセルへの接続
最後に、次の2つの仕組みを加えます。
- Asanaのタスクが期限を超過したとき ── 取引担当者へ通知する仕組みです
- 検収後 ── 更新やアップセルの検討タスクを作る仕組みです
通知は、受け取った担当者がその日のうちに行動を決められる条件に絞ってください。一定期間運用して、開かれないまま残っている通知があれば、その条件から外していきます。
検収後のタスクは、デリバリーで得た顧客の声を次の提案に活かすための入り口になります。
HubSpot × Asana連携の注意点と限界
連携は便利な一方で、設計を誤ると保守の負担が増え、かえって現場を混乱させることがあります。また、ツールやAPIの仕様上、できないことや制限もあります。導入前に押さえておきたい点を率直にまとめます。
過度な連携は複雑性を増す
すべてのHubSpotイベントをAsanaに連携し、すべてのAsanaタスクをHubSpotに反映しようとすると、連携フローが複雑になりすぎてメンテナンスが大変になります。
連携は次の2つに絞るのが現実的です。
- 受注時のプロジェクト自動作成
- 主要マイルストーンのステータス連携
新しい連携を追加したくなったときは、「その連携がないと誰がどんな手作業をしているか」を書き出してみてください。
- 手作業が頻繁に発生していて、ミスが顧客対応に影響している ── 追加する価値があります
- 発生頻度が低く影響も小さい ── 手作業のままにしておく方が全体の保守は楽になります
Asana以外のプロジェクト管理ツールも候補になる
Backlog、Jira、Monday.comなど、他のプロジェクト管理ツールとの連携も選択肢に入ります。
Asanaはタスクの視覚的な管理に優れていますが、次の場合は他のツールの方が馴染む場合もあります。
- ソフトウェア開発 ── Jira
- 日本の受託開発 ── Backlog
選ぶ基準は、デリバリーチームが日々どのような単位で作業を管理しているかです。
- 課題やチケットの単位で細かく進捗を追う開発中心のチーム ── JiraやBacklog
- 複数の部門が関わる業務を視覚的に並べて進めるチーム ── Asana
自社のプロジェクト特性に合わせて選択してください。すでに現場で定着しているツールがあれば、それを置き換えるよりもHubSpotと連携させる方が、導入の負担は小さくなります。
iPaaS連携の保守コストと停止時の備え
Yoom・Zapier経由の連携を使う場合、次の2つがかかります。
- iPaaSツールのサブスクリプション費用
- 連携フローのメンテナンス工数
連携の複雑さに応じてコストが増加するため、自動化で削減できる手作業の量と比べたうえで、どこまで自動化するかを決めることをおすすめします。
また、iPaaS連携が停止すると、Asanaのプロジェクト自動作成が行われなくなります。停止に早く気づけるよう、次のように備えておくと安心です。
- 第1段階で紹介した「契約締結した取引とAsanaプロジェクトの見比べ」 ── 定期的な運用として残しておきます
- 手動でプロジェクトを作る手順 ── 漏れが見つかったときのために文書にしておきます
APIの実行制限を前提に設計する
Asana APIには、次の実行回数の上限があります（出典：Rate limits | Asana Developers）。
- 無料プランのドメイン ── 1分あたり150リクエスト
- 有料プランのドメイン ── 1分あたり1,500リクエスト
日々の取引ごとにプロジェクトを作る程度であれば問題になりにくいものの、過去の取引をまとめてAsanaへ登録するような一括処理では上限に達しやすくなります。
一括処理が発生する場合は、次のいずれかを選べます。
- 対象を小分けにして時間をずらして実行する
- 初期データの登録にはAsanaのCSVインポートを使う（出典：Asana「Project importing and exporting」）
連携は、日々発生する新しい取引の処理に専念させる形が安定します。
よくある質問
Q1. HubSpot公式のAsanaアプリは無料ですか？
アプリのインストール自体は無料です。ただし、ワークフロー内のカスタムコードからAsana APIを呼び出すには、Data Hub Professional以上が必要です（出典：HubSpot「Custom code workflow actions」）。また、Asana側もプランによってプロジェクトテンプレートなどの使える機能が変わるため、契約中のプランで独自テンプレートを作れるかを先に見ておくと、設計の手戻りを防げます。
Q2. Asanaを使っていないチームメンバーもプロジェクト情報を見られますか？
HubSpotの取引レコードにAsanaのプロジェクトリンクが記録されるため、HubSpotのアクセス権があれば、プロジェクトの存在と基本情報は把握できます。詳細なタスク管理にはAsanaアカウントを使います。営業に主要マイルストーンの状況だけ見せたい場合は、第2段階のステータス連携で取引プロパティに記録しておくと、Asanaアカウントがなくても進捗を追えます。
Q3. 受注後のプロジェクトだけでなく、営業活動のタスクもAsanaで管理すべきですか？
営業活動のタスク（架電、メール送信、資料作成など）は、HubSpotのタスク機能で管理する方が効率的です。CRMの顧客情報と直結しているため、画面を行き来する手間が少なく済みます。Asanaはデリバリー・プロジェクト管理に特化させる使い分けをおすすめします。
Q4. 連携が途切れた場合のリスクは？
iPaaS連携が停止した場合、Asanaのプロジェクト自動作成が行われなくなります。契約締結した取引とAsanaのプロジェクトを定期的に見比べる運用を残し、手動でもプロジェクトを作成できるフォールバック手順を用意しておくと安心です。手順は取引ステージの定義と同じ場所に置いておくと、担当者が変わっても迷わずに対応できます。
まとめ
HubSpotとAsanaの連携により、CRMの商談管理とプロジェクト管理を統合し、受注からデリバリーまでの全体フローを一元管理できます。押さえておきたいポイントは次のとおりです。
- 顧客のマスターデータはHubSpot、プロジェクトの実行管理はAsanaと役割を分けることで、二重管理を防げます
- Asanaのプロジェクト作成は「契約締結」以降にし、ステージ定義と必須プロパティで引き継ぎ情報の質を揃えます
- 連携は「受注時のプロジェクト自動作成」から始め、ステータス連携やアラートを段階的に追加していきます
- 営業とデリバリーの情報の断絶を解消することで、顧客体験の一貫性が保たれ、リピートやアップセルにもつながっていきます
まずは、契約締結でAsanaのプロジェクトが1件作られるところから始めてみてください。次の3ステップで進めると、無理なく形にできます。
- 契約締結ステージの定義と、デリバリー開始に欠かせない必須項目を社内で決める
- 最も件数の多い案件種別で、Asanaのプロジェクトテンプレートを1つ作る
- 公式アプリまたはYoom・Zapierで、契約締結をきっかけにプロジェクトを作る連携をテスト用の取引で試す
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
