%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では、取引ステージの「成約」を起点にワークフローを動かし、チケットやプロジェクトのレコードを作成し、請求情報を会計側へ渡すところまでを、一本の流れとして設計できます。
営業の頭の中にあった導入目的や納期の約束が、受注の直後に口頭やチャットでしか渡されない——この断絶が、立ち上げの遅れや二重ヒアリングの原因になります。取引から何を引き継ぐかを先に決め、その項目が空のままでは受注にできない状態にしておくことが、設計の出発点です。
この記事でわかること：
- 引き継ぎ項目の定義表 ── 営業が入力する項目と、受け取る側が使う場面を対にして決める方法
- 取引ステージの必須入力の設定場所 ── 公式ナレッジで確認した画面の場所と手順
- チケットとプロジェクトの選び分け ── 受注後の作業の性質で判断する表
- 請求への接続 ── Sync for freeeで取引から見積書・請求書・会計までつなぐ範囲と、人の確認を置く位置
受注の瞬間に引き継ぎが途切れる場所を洗い出す
受注後の引き継ぎがうまくいかない原因は、担当者の意識よりも、情報の置き場と起動の条件が決まっていないことにあります。まず、どこで何が落ちるのかを工程ごとに分けて確認します。
引き継ぎで落ちやすい情報
営業の段階で把握していて、受け取る側が必要とする情報は、おおむね次のように分類できます。それぞれが「取引のどこに残るか」を決めていないと、メールやチャットの中に埋もれます。
| 落ちやすい情報 | 受け取る側が困る場面 | 残す場所の例 |
|---|---|---|
| 導入の目的・期待する成果 | キックオフで同じ質問を繰り返す | 取引のプロパティ（複数行テキスト） |
| 契約の開始日・提供範囲 | 作業の着手日や範囲の認識がずれる | 取引のプロパティ（日付・ドロップダウン） |
| 先方の窓口と役割 | 誰に連絡すべきか分からない | 取引とコンタクトの関連付けラベル |
| 請求の条件（締め・請求先） | 請求書の発行時に営業へ問い合わせる | 取引の商品項目と請求関連プロパティ |
| 約束した特別対応 | 後から「聞いていない」となる | 取引のメモ・必須入力の項目 |
起動の条件が人の判断になっている
もう一つの原因は、引き継ぎを始めるきっかけが「営業が連絡したとき」になっていることです。営業が忙しい月ほど連絡が遅れ、受注から着手までの間が空きます。ワークフローで取引ステージの変化を起点にすれば、連絡の有無にかかわらず、受け取る側のタスクとレコードが作られます。
引き継ぎ項目を定義し、取引ステージの必須入力にする
自動化の前に決めるのは、引き継ぐ項目の定義です。項目が曖昧なままワークフローを作っても、空欄のレコードが量産されるだけです。
引き継ぎ項目の定義表の作り方
次のように、項目ごとに「誰が入力するか」「いつまでに入力するか」「受け取る側がどう使うか」を決めて表にします。企業様（チーム）によって最適な形は異なりますので、最初は5〜8項目に絞って始めることをお勧めします。
| 列 | 書く内容 | 例 |
|---|---|---|
| 項目名（表示名） | 現場で通じる名前 | 契約開始日 |
| 入力する人 | 営業担当者 | 取引の担当者 |
| 入力のタイミング | どのステージで入力するか | 契約書送付済みから成約へ移るとき |
| 受け取る側の使い道 | どの作業の起点になるか | プロジェクトの開始日として使う |
| 空欄のときの扱い | 受注にできるか | 必須。空欄なら成約に移せない |
成約ステージで必須入力にする手順
HubSpotの取引ステージには、特定のステージへ移すときに入力させるプロパティを設定する「条件付きロジックルール」があります。公式ナレッジで確認した手順は次のとおりです。
- 上部ナビゲーションバーの設定アイコンをクリックし、左サイドバーの［データ管理］セクションで［オブジェクト］を選びます。
- ［オブジェクトを選択］で［取引］を選び、［パイプライン］タブを開きます。
- 対象のパイプラインを開き、ステージ行の［条件付きロジックルール］列から［ルールを追加］を選びます。
- 演算子とステージ、依存プロパティを指定し、依存プロパティの［必須］にチェックを入れて［ロジックを保存］します。
必須にしたプロパティは、そのステージでレコードを作成するとき、または既存のレコードをそのステージへ移動するときに自動で表示されます。値が入るまでレコードを更新できないため、引き継ぎ項目の入力漏れを入口で防げます。なお、スコアや計算プロパティなど、読み取り専用の値が入るプロパティはステージプロパティに選べません。
引き継ぎの品質は、ワークフローの精緻さよりも「成約に移す時点で必要な項目が埋まっているか」で決まります。必須入力は、営業に負担を増やすのではなく、受注後の聞き直しをなくすための設定です。
画面の詳細はHubSpotパイプライン設計ガイドでも、取引ステージと確度の決め方とあわせて整理しています。
「成約」を起点にするトリガーの設計
取引ステージの「成約」は、HubSpotの取引パイプラインで扱いがあらかじめ決まっているクローズ済みのステージです。公式ナレッジでは、「成約」と「失注」の両方を取引確度に含めておくことが、セールスレポートや収益レポートで取引を正しく処理する前提とされています。
受注内示と契約締結を分ける
ワークフローを起動するのは、口頭で受注が決まった時点ではなく、契約締結が確定した時点にします。内示の段階でプロジェクトやチケットを作ると、白紙に戻った案件の残骸が受け取る側に溜まります。パイプラインの中に「内示」と「契約書送付済み」のステージがあれば、起動するのは最後の「成約」だけにして、手前のステージでは何もしない設計が安全です。
登録条件と再登録の考え方
ワークフローの登録条件は、取引の［取引ステージ］が［成約］であることを基本にします。ワークフローは作成時にレコードのタイプを選ぶと、後から変更できません。取引を起点に動かすため、最初に「取引ベース」で作成します。再登録を許可すると、ステージの行き来のたびに引き継ぎ用のレコードが重複するため、原則はオフにして、修正が必要なときは手動で扱います。作成した直後は、テスト用の取引で動作を確認してから有効にします。登録の履歴の見方はHubSpotワークフローが動かない原因と確認手順にまとめています。
チケットとプロジェクトの選び分け
受注後に作るレコードは、チケットとプロジェクトのどちらかを選ぶ場面が多くあります。作業の性質で判断します。
判断表：作業の性質で選ぶ
| 受注後の作業の性質 | 向くレコード | 理由 |
|---|---|---|
| 設定・初期対応など、1つの依頼として完結する | チケット | ステータスで進行と完了を管理できる |
| 複数の工程・担当者・期間にまたがる | プロジェクト | ステージでマイルストーンを表し、複数のレコードを関連付けられる |
| 定型の作業を1件ずつ確実にこなす | タスク | 担当者と期限だけで足りる |
| 継続的な問い合わせ対応が始まる | チケット（サポート用のパイプライン） | 受注後の窓口として、そのまま運用に移れる |
チケットで引き継ぐ場合の設計
ワークフローの［レコードを作成］アクションでは、コンタクト・会社・取引・チケット・リード・カスタムオブジェクトのレコードを自動作成できます。公式ナレッジの一覧では、チケットを作成するには Service Hub の Professional または Enterprise が必要とされています。受注後のオンボーディング用に、通常のサポートとは別のパイプラインを用意すると、集計も分けられます。
チケットのパイプラインは、設定アイコン＞［データ管理］の［オブジェクト］＞［チケット］＞［パイプライン］タブで編集します。ステージ（チケットでは既定で「ステータス」と呼ばれます）は、「進行中」か「クローズ済み」のどちらかとして追加します。また、カスタムパイプラインの作成は Starter 以上で利用でき、上限数はプランによって異なります。
プロジェクトで引き継ぐ場合の設計
複数工程に分かれる納品には、プロジェクトのオブジェクトが使えます。公式ナレッジでは、プロジェクトのオブジェクトの有効化にスーパー管理者の権限が必要で、手順は次のとおりです。
- ［その他］から［データ管理］＞［データモデル］に移動します。
- 右上の［データモデルを編集］をクリックします。
- プロジェクトを選び、［オブジェクトを有効化］をクリックして、ダイアログで［確認］をクリックします。
- 有効化後は［CRM］＞［プロジェクト］に表示されます。
取引・コンタクト・タスクなどとの関連付けは、データモデルビルダーで設定します。プロジェクトのパイプラインのステージ名は、設定＞［オブジェクト］＞［プロジェクト］＞［パイプライン］タブで編集でき、ステージを「キックオフ」「最終サインオフ」のようなマイルストーンにできます。パイプラインルールを使うと、ステージのスキップを制限し、作成時の既定ステージを選べます。なお、パイプラインルールとワークフローは、Professional または Enterprise のサブスクリプションが必要と記載されています。
公式ナレッジには、取引ステージが「成約」になったらプロジェクトを自動作成するワークフローの手順も載っています。フィルター条件で取引の［取引ステージ］を選んで［成約］を指定し、［レコードを作成］アクションでプロジェクトを選んで詳細を設定し、保存してオンにする流れです。外部のプロジェクト管理ツールと連携する場合の考え方は、HubSpot×Asana連携の設計で整理しています。
担当者の割り当てとタスクで「誰が動くか」を決める
レコードを作っただけでは、誰が最初に動くのかが決まりません。受け取る側の担当と最初の作業を、ワークフローの中で確定させます。
公式アクションで組める要素
ワークフローのアクション一覧で確認できた、引き継ぎに使えるものを整理します。
| やりたいこと | アクション | 確認できた条件 |
|---|---|---|
| 受け取る側の担当を順番に割り当てる | レコードを担当者にローテーション | Sales Hub・Service Hub の Professional・Enterprise。有効な有料ユーザーのみ |
| 最初の作業を作る | タスクを作成 | 条件の記載なし |
| 経緯を残す | メモを作成 | 条件の記載なし |
| 取引とチケット等をつなぐ | 関連付けを作成 | 条件の記載なし |
| 取引から見積書・請求書の草案を作る | 見積もりを作成／請求書に変換 | 条件の記載なし |
担当の決め方は、顧客ごとに固定する方法と、順番に割り当てる方法に分かれます。契約後も同じ窓口が望ましい業態では、営業が入力した「CS担当」のプロパティを使い、ローテーションは担当が空のときの代替にします。タスク自動化の設計はHubSpotタスク自動化の設計も参照してください。
Service Hub のシートとカスタマーサクセスワークスペース
プロジェクトをカスタマーサクセスワークスペースで表示するには、Service Hub のシートの割り当てが必要とされています。受け取る側のユーザーにシートがないと、作った情報が見えない状態になります。ワークフローを組む前に、受け取る担当者のシートと権限を確認します。CS側の運用全体はHubSpotカスタマーサクセスの設計で扱っています。
請求情報をSync for freeeで会計へつなぐ
引き継ぎのもう一つの出口が請求です。受注後の請求は、営業の取引情報を経理が二重入力する工程になりがちです。StartLinkが開発した連携アプリ Sync for freee では、HubSpotの取引を起点に、freeeの見積書・請求書・会計の取引までをつなげられます。
公開情報で確認できた連携の範囲
Sync for freee の公式ページで確認できた機能を、受注後の流れに当てはめます。
| 受注後の工程 | Sync for freee の機能 | 人が確認すること |
|---|---|---|
| 請求先の登録 | 会社から freee会計の取引先を作成（重複チェックあり） | 取引先名・請求先の正しさ |
| 請求書の作成 | 取引から請求書を作成、見積書から請求書へ変換 | 品目・単価・税区分 |
| 会計への登録 | 成約した取引を freee会計に登録 | 勘定科目と税区分 |
| 入金の把握 | freee側の入金消し込みを HubSpot の決済状況へ反映（定期バッチ） | 反映はリアルタイムでない点 |
| 未入金の追跡 | ワークフローアクション「未入金請求書チェック」 | 督促の判断 |
月次・年次の継続請求は Professional 以上、複数商品項目の合算請求は Enterprise 以上と記載されています。また、公式ページには、生成されたデータは利用者が最終確認する前提であり、金額・税区分・取引先情報は運用ルールに沿って確認・承認する必要があると明記されています。引き継ぎのワークフローも、請求書を自動で確定させる設計にせず、確認のタスクを担当者に作るところまでにとどめます。
引き継ぎ項目と請求の対応
請求の自動化が崩れる原因の多くは、取引側の項目が不足していることです。成約時の必須入力に、請求先の会社の紐付け、商品項目、請求の開始時期を含めておくと、請求の工程で営業へ問い合わせる往復が減ります。会計連携の全体像はfreee HubSpot MCP連携の解説、営業から請求までのAIの分担は営業から請求までのAI業務設計でも整理しています。
受注後の引き継ぎ設計を進める工程
StartLinkの支援では、受注後の引き継ぎを、一度に作り込まず、小さく始めて広げる進め方を取ります。HubSpotゴールドパートナーとして、現状の整理から定着までを準委任で伴走します。
工程ごとの作業と成果物
| 工程 | 受注後の引き継ぎでの作業 | 成果物 |
|---|---|---|
| 現状整理・要件定義 | 直近の受注案件を数件たどり、営業から受け取る側へ渡った情報と、聞き直しが起きた項目を洗い出す | 引き継ぎ項目の定義表の案 |
| 設計・構築 | 取引ステージの必須入力、受け取る側のレコード（チケットかプロジェクト）、ワークフロー、請求連携を設計・構築する | パイプライン設計書、ワークフロー設計書 |
| データ移行 | 進行中の案件の取引情報を、新しい項目へ揃えて取り込む | 件数と項目の照合表 |
| テスト・検証 | テスト用の取引で、成約から作成されるレコード、担当、タスク、請求の確認までを通す | 検証の記録 |
| 定着・運用改善 | 実際の受注で起きた漏れを見直し、項目と起動条件を調整する | 改善後の定義表 |
最初は、受注後の作業が最も多い1つのパイプラインから始め、安定してから対象を広げます。連携アプリの Sync for freee や Sync for Notion で埋められる部分は既存の機能を使い、ワークフローとBreezeなどのAIは、要約や分類のような判断が人に戻る箇所に限って組み込みます。設計書の書き方はHubSpotワークフロー設計書の書き方を参考にしてください。
運用で崩れる点と回避策
引き継ぎの仕組みは、作った直後よりも、運用に入ってから崩れます。典型的な崩れ方と回避策は次のとおりです。
| 崩れ方 | 原因 | 回避策 |
|---|---|---|
| 同じ案件のレコードが重複する | ステージの行き来で再登録される | 再登録を原則オフにし、修正は手動で扱う |
| 空欄のままレコードが作られる | 必須入力がない | 成約ステージの依存プロパティを必須にする |
| 受け取る側が気づかない | 担当が空、またはシートがない | 担当の補完とシートの事前確認 |
| 内示の段階でレコードができる | 起動のステージが早い | 契約締結後の「成約」だけを起点にする |
| 請求の内容が営業の意図とずれる | 請求書を自動確定している | 確認のタスクを担当者に作る |
設計を進める手順
- 直近の受注を数件たどり、受け取る側が聞き直した情報を書き出します。
- 引き継ぎ項目の定義表を作り、入力する人とタイミングを決めます。
- 取引パイプラインの「成約」ステージに、必須の依存プロパティを設定します。
- 受注後の作業の性質で、チケット・プロジェクト・タスクのどれを作るかを決めます。
- 取引ベースのワークフローを作り、登録条件を「成約」にします。
- 担当の割り当てと最初のタスクを入れ、請求は確認のタスクまでを自動化します。
- テスト用の取引で通し、実際の受注で漏れを見直します。
よくある質問
Q1. 受注したらプロジェクトを自動で作るには、どうしますか
ワークフローで、取引の［取引ステージ］が［成約］になったことを登録条件にし、［レコードを作成］アクションでプロジェクトを選びます。事前に、プロジェクトのオブジェクトを［データ管理］＞［データモデル］で有効化しておく必要があります。ワークフローとパイプラインルールには Professional または Enterprise が必要と記載されています。
Q2. チケットとプロジェクトのどちらで引き継ぐべきですか
1つの依頼として完結する作業はチケット、複数の工程や担当者にまたがる作業はプロジェクトが向きます。チケットの作成は Service Hub の Professional または Enterprise、プロジェクトは取引やコンタクトなどを関連付けて管理できます。迷う場合は、最も作業の多い案件を1つ選び、どちらで管理すると進捗が見えやすいかを試して判断します。
Q3. 営業に入力を増やしたくない場合はどうしますか
最初は5〜8項目に絞り、受け取る側が「聞き直した」実績のある項目だけを必須にします。入力の負担は、受注後の聞き直しが減ることで相殺されます。項目が増えすぎると入力が形骸化するため、定着後に見直します。
Q4. 請求書の発行まで完全に自動化できますか
Sync for freee では、取引から請求書を作成できますが、公式ページでは、金額・税区分・取引先情報を利用者が確認・承認する前提と明記されています。引き継ぎのワークフローは、確認のタスクを担当者に作るところまでを自動化し、確定は人が行う設計が適切です。
Q5. 既存の案件の引き継ぎ情報も揃えられますか
進行中の案件は、データ移行の工程で新しい項目へ揃えて取り込みます。項目が空の案件は、担当者が確認して補い、件数を照合表で管理します。
まとめ：成約ステージを起点に、項目・レコード・請求を順に決める
- 引き継ぎ項目は、営業の入力と受け取る側の使い道を対にした定義表で決める
- 取引ステージの［条件付きロジックルール］で、成約に移す時点の必須入力にする
- 起動は契約締結後の「成約」だけにし、再登録は原則オフにする
- 作業の性質でチケット・プロジェクト・タスクを選び、担当とタスクを同じワークフローで確定する
- 請求は Sync for freee で取引から会計へつなぎ、確定は人の確認を置く
最初の一歩は、直近の受注案件を数件たどり、受け取る側が聞き直した情報を書き出すことです。自社の状況に当てはめた進め方を検討したい場合は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお問い合わせください。
出典・参考
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
