HubSpotとNotionの連携｜受注後の引き継ぎを必須項目と変更管理から設計する

HubSpotとNotionの連携では、営業が受注した情報を、制作・開発のプロジェクトへ引き継ぐ使い方ができます。既存アプリや自動化サービスでページ作成を行い、要件が複雑ならAPIを使って補う構成です。

この記事では、受注時の自動作成に加え、制作側が受け入れられる情報を揃えることを中心に説明します。CRMを丸ごと複製するのではなく、契約条件と進行管理の役割を分ける設計例です。

HubSpotとNotionで管理する情報を分担する

情報	主な管理先の例	連携の方針
顧客・商談・受注金額・営業担当	HubSpot	確定した項目を参照する
契約範囲・成果物・除外事項	契約書等の正本と受注情報	原本へのリンクと確認済みの要点を渡す
制作タスク・議事録・進行メモ	Notion	制作側で更新する
引き継ぎ状態・差戻し理由	Notion等の引き継ぎ台帳	営業と制作が次の担当を確認する
案件ページURL・プロジェクトID	双方に参照情報として保存	元の商談と案件を辿れるようにする

HubSpotとNotionの両方から受注金額を自由に直せる運用にすると、どちらが正しいか判断しづらくなります。同期する項目ごとに、どちらの担当者が変更してよいかを決めましょう。

まず既存アプリで足りる範囲を確認

HubSpotのマーケットプレイスには、NotionのページやDBとつなぐアプリが掲載されています。たとえばStartLinkの「Sync for Notion」は、HubSpot画面からのNotion操作に加え、ワークフローでのページ作成・更新等を案内しています。

HubSpot Marketplace：Sync for Notion

つまり、受注に応じたページ作成をすべて自作する必要があるとは限りません。比較するときは次の条件を確認します。

選択肢	比較したい条件
既存の連携アプリ	取引・会社・コンタクト等の対応、ページ作成、項目設定
自動化サービス	ステージ変更の検知、条件分岐、既存ページの検索・更新
APIによる個別実装	複数契約・複数プロジェクト、独自の受入条件、実行記録

HubSpotのワークフローや連携アプリには、契約する製品・プランごとの条件があります。アプリが使えることと、必要な自動処理を今の契約で組めることは別に確認しましょう。

引き継ぎの必須項目を決める

制作・開発担当者に「この案件を進められるか」を判断してもらうため、項目を次のように分けます。

項目	記録例・確認すること
商談ID	HubSpotの対象レコードを一意に識別
成果物	何をどこまで納品するか
対象外	運用代行、追加ページ、データ整備など含まない範囲
納期と前提	顧客から素材や認可が揃う日を含む
検収・完了条件	誰が何を確認すると完了か
顧客側の担当・決裁者	確認依頼を出す相手
原本	見積・契約・合意メールへのリンク
未決事項	未確定の項目と、営業が確認する期限
引き継ぎ版・受入担当	どの内容を誰が確認したか

架空の例として「Webサイト一式」という商談があっても、フォーム実装、原稿作成、既存記事の移行が含まれるかは分かりません。受注金額だけで制作タスクを確定すると、営業の想定と制作の理解がずれたまま進みます。

必須項目が空なら、空のタスクを大量に作るより「引き継ぎ情報待ち」として営業へ戻します。ページ自体を先に作る場合も、制作開始済みと区別できる状態にしましょう。

受注から制作受入までのフロー

1. HubSpotで対象の商談が受注の状態になったことを検知する。
2. 商談IDでNotionの既存案件を探し、重複作成を防ぐ。
3. 必須項目と原本のリンクを確認し、引き継ぎ候補を作る。
4. 不足があれば営業担当へ差し戻す。
5. 制作の受入担当が範囲・納期・前提を確認する。
6. 受入後にプロジェクトの担当、日程、タスクを確定する。

「受注」「引き継ぎ作成」「制作受入」「着手」は別々の状態です。状態を細かくする目的は管理項目を増やすことではなく、次に営業と制作のどちらが動くかを明確にすることです。

既存アプリでページ作成とリンク保存まで行える場合は、その機能を使い、受入判断をNotionの確認ビューで行うだけでも始められます。

受注後の条件変更を無言で上書きしない

制作開始後に、納期や成果物が変わることがあります。このときHubSpotの項目をNotionへ上書きするだけでは、既に組んだタスクや担当者の合意が取り残されます。

変更の例	対応の考え方
納期を前倒し	制作側が対応可否と影響を確認して再合意
成果物を追加	追加契約・費用の確認とタスクの追加を分ける
受注を取り消し	取消状態を残し、進行中作業を止める担当を決める
商談のステージが再び受注へ戻る	同じ商談IDの既存案件を確認し、別案件を増やさない
1商談から複数案件を作る	商談IDに加え、案件の枝番・区分を管理する

引き継ぎ時の内容を記録し、更新後との差を確認できると、何を再確認すべきか分かります。同期処理だけで、契約変更の承認まで完了した扱いにしないようにしましょう。

AIは引き継ぎ案と不足項目の整理に使う

AIに営業メモや議事録を渡す場合は、成果物・対象外・未決事項を分けた引き継ぎ案を作らせます。原文にない納期や合意事項は補わず、「未確認」とする指示を入れます。

たとえば次のような出力を求めます。

合意が確認できる内容、提案段階の内容、記載がなく確認が必要な内容を分けてください。各項目に元資料を付け、契約上の確定判断はしないでください。

その案を営業と制作が確認してから、正式な引き継ぎへ反映します。顧客の機密情報を外部AIへ送ってよいかも、利用サービスの条件と社内ルールで確認します。

Notion APIと外部AIで下書きを作る構成

導入時の確認チェック

ケース	期待する結果
必須項目が揃った受注	正しい商談にひも付いた引き継ぎを作る
不足した受注	制作開始に進めず、営業への確認事項を出す
同じイベントを再処理	既存の案件を参照し、重複を増やさない
制作側が受け入れていない	受入待ちの担当者と期限が分かる
受入後の変更	差分と再確認の必要性が分かる
連携が途中で失敗	ページ作成とリンク返却のどちらが済んだか追える

最初は一つの営業パイプライン、一つの制作種別で始めます。引き継ぎまでの日数や確認の往復数を測ると、単なる転記時間の短縮以外の効果も見えます。

ビットライトでは、受注から制作までの項目・担当・受入条件を整理し、既存アプリで足りる範囲と追加開発を比較できます。今の受注票や引き継ぎメモをもとにご相談ください。

Notion AIの業務連携ホワイトペーパーを請求する

仕様確認：2026年10月21日。掲載した引き継ぎフローは設計例で、連携アプリの全機能を保証するものではありません。契約プラン・項目・操作の対応は導入時に確認してください。

Notionの業務連携について相談する