%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}
この記事の結論
販売管理とCRMの役割は、受注前と受注後で分かれます。受注を境界にデータをつなぐ設計が、営業から請求までの流れを支えます。
販売管理とCRMの役割は、受注前と受注後で分かれます。受注を境界にデータをつなぐ設計が、営業から請求までの流れを支えます。
「CRMに商談は記録しているのに、受注後はExcelに転記している」
「受注を営業から聞いて、バックオフィスが販売管理に入力している」
「請求や入金の状況が、次の営業活動に生かされていない」
販売管理とCRMの違いは、CRMが受注前の顧客関係や商談を管理し、販売管理が受注後の納品・請求・入金を管理する点です。両者を受注の定義と共通データでつなぐと、顧客情報を引き継ぎ、受注後の状況を営業活動へ戻せます。
本記事は「販売管理とは？業務フロー・システム化のメリット・選び方を基礎から解説」シリーズの一部です。
この記事でわかること
販売管理とCRMの役割を整理し、受注を境にどの情報をどう連携するかを解説します。Excelなどへの転記が残っている場合は、まず業務上の受け渡しとデータ定義を確認する材料として活用できます。
- CRMと販売管理の違い — 管理する業務フェーズ、データ、利用部門を比較します。
- 受注で業務が分断される理由 — 二重入力や情報共有の遅れが起きる背景を整理します。
- 連携の基本設計 — 受注時の連携、顧客マスタの扱い、受注後情報のフィードバックを紹介します。
- 連携を始める手順 — 共通データと受注条件を決め、小さく確かめて広げる進め方を説明します。
最後まで読むと、自社の受注の定義、連携する項目、エラー時の担当を一覧にして、最初に連携する1つの業務を決められる状態になります。
CRMと販売管理は、受注前後で役割が分かれます
CRMと販売管理は、同じ顧客に関わる情報を扱いますが、目的と業務上の役割は異なります。
CRMは顧客との関係や商談の進行を支え、販売管理は受注後の業務を正確に進めるための仕組みです。
連携を考える前に、各部門がどの時点でどの情報を必要とするかを整理すると、受け渡す項目と管理先を決めやすくなります。
CRMが担う顧客・商談の管理
CRMは、顧客情報、担当者とのやり取り、営業活動、商談の進捗などを管理します。営業の進捗を管理するときは、顧客情報と個別案件の状況を分けて確認します。
- 顧客情報 ── 会社や担当者に関する情報を置きます。
- 商談 ── 対象の提案や進捗、予定している金額や日付を記録します。
- 顧客と商談の関係 ── 関係を保つことで、別の案件が始まった場合も顧客との接点を追いやすくなります。
見込み客への対応から商談、受注までの状況を同じ場所で確認し、次に取る営業アクションや売上の見通しを検討するための基盤です。
営業の状況を担当者の記憶や個別の表計算に閉じ込めず、顧客とのやり取りと商談の状態をつなげて把握することがポイントです。商談ステージの定義が明確になれば、担当者間で進捗の読み方も揃えやすくなります。
販売管理が担う受注後の業務
販売管理は、受注が決まった後の注文内容、納品、請求、入金などを管理する仕組みです。
- 管理する対象 ── 注文内容、納品、請求、入金。商品を扱う場合は、在庫や出荷の情報も対象になります。
- 処理の中心 ── 営業活動の履歴よりも、確定した数量、金額、日付、取引条件を正確に処理することです。
CRMで商談が受注になっても、納品先や請求条件が自動的に整理されるとは限りません。受注後の業務を表計算やメールで補っている場合、入力の重複や確認の手間が生じやすくなります。
営業から引き継ぐ情報と、販売管理で確定・補完する情報を分けておくと、入力の責任範囲や不足項目を確認しやすくなります。
どちらが必要かは、業務の範囲で考える
CRMと販売管理は、片方がもう片方を全面的に置き換える関係ではありません。
- 商談の見通しを管理したい場合 ── CRMの役割が必要です。
- 受注後の出荷、請求、入金照合を扱う場合 ── 販売管理の機能が関係します。
| 比較項目 | CRM | 販売管理 |
|---|---|---|
| 主な目的 | 顧客関係と商談の管理 | 受注後の業務処理 |
| 管理する情報 | 顧客、担当者、活動履歴、商談 | 受注、納品、請求、入金、在庫 |
| 主な業務フェーズ | リード獲得から受注まで | 受注から納品・回収まで |
| 情報の性質 | 関係性、行動、見込み | 金額、数量、日付、確定条件 |
| 主な利用部門 | 営業、マーケティング | 営業事務、経理、バックオフィス |
ただし、製品ごとに扱える業務の範囲は異なります。見積作成、受注確定、納品状況の更新、請求処理を順に並べ、各工程で次の点を確認します。
- 入力するシステム
- 確定情報を持つシステム
- 次に情報を使う担当者
そのうえで、CRM内で完結できる工程と、在庫・会計システムとの連動が必要な工程を整理します。必要な情報を次の工程へ渡せない場合は、手作業や別の仕組みが必要になるため、機能名だけで判断せず業務の入口から完了まで確かめます。
Excelや手作業が残ると、受注が引き継ぎの断点になります
CRMと販売管理の間で情報を手渡ししていると、受注を境に入力先と担当部門が切り替わります。口頭連絡やメール、表計算への転記が加わるほど、どの情報が確定済みかを追いにくくなります。
受注を単なるステージ変更ではなく、営業からバックオフィスへの引き継ぎとして設計することが重要です。
受注の連絡を受けた側について、次を決めておくと、引き継ぎ時の判断が担当者任せになりにくくなります。
- 処理を始めるときに見る情報 ── どの情報を見て処理を始めるか
- 差し戻しの条件 ── 何が不足していたら差し戻すか
二重入力は情報の差を生みます
CRMに登録した顧客名や金額を、別の担当者が販売管理へ入力すると、表記や値が一致しないことがあります。業務上の定義が曖昧な項目ほど確認が必要になります。
- 顧客名の略称 ── 表記が揃わない原因になります。
- 税抜と税込の違い ── 同じ金額でも意味が変わります。
- 商品コードの欠落 ── 後工程で照合できなくなります。
この状態を個人の注意だけで防ぐのは難しく、引き継ぎのたびに確認作業が増えます。
何を受注確定とみなすか、どの項目が揃えば後工程に渡せるかを決め、仕組みで同じ確認ができる形にすると、担当者が変わっても処理を続けやすくなります。
例えば、次の場合に、誰がどの情報を確認して修正するかを決めます。
- 受注日が未入力の場合
- 顧客IDと顧客名の組み合わせが一致しない場合
確認対象と修正担当が明確であれば、再入力や問い合わせが必要な理由も追いやすくなります。
CRMだけでは請求や入金まで見えないことがあります
CRMの主な目的は、顧客や商談、営業活動を管理することです。受注後の商品数量や納品状況、請求書の発行、入金確認までを同じ粒度で扱えるとは限りません。
CRM上で受注後の作業を補う場合、請求済みか、入金があったかといった状態を別の表で管理することがあります。管理場所が分かれる場合は、どのシステムが確定情報を持つのかを決め、必要な状態だけを相互に参照できるようにします。
例えば、次のどちらにするかで、連携項目と更新責任が変わります。
- 請求額や入金額そのものをCRMで更新する
- 営業が必要とする請求・入金の状態だけを参照する
確定値を持つ場所と、営業が確認する場所を区別しておくと、情報が食い違ったときの確認先も判断できます。
販売管理だけでは商談の経緯が見えにくくなります
販売管理は確定した受注を起点とするため、受注に至るまでの顧客とのやり取りや提案内容が十分に記録されない場合があります。営業が次の提案を考えるとき、購入履歴だけでは顧客の検討背景や過去の課題を把握しにくいことがあります。
このため、受注後の情報をCRMに戻す設計も検討します。販売管理にある納品実績や請求履歴、入金状況のうち営業活動に必要な項目を決め、顧客や取引のレコードに紐づけておくと、次の対応を考える材料になります。
- 戻す項目の選び方 ── 営業がその情報を見てどの判断をするのかを明らかにします。
- 戻しすぎへの注意 ── 判断に使わない詳細まで複製すると、確認すべき情報が増えます。
- 定義するもの ── 参照目的と更新元をセットで定義します。
受注を境界に、CRMと販売管理をつなぎます
連携は、すべての項目を両システムへ複製することではありません。
連携とは、どの情報をどちらで正として持ち、どの業務イベントで相手側へ渡すかを決める作業です。
最初に受注の確定条件を定義し、その条件を満たした取引から必要な情報を連携させます。設計時には、受注前に変わる見込み情報と、受注後に確定する取引情報を区別し、変更が起きたときの更新元も決めます。
連携前に受注の定義を揃える
CRM上の「受注」と販売管理上の「受注」が異なる意味だと、データを送るタイミングもずれます。例えば、営業が口頭で合意を得た段階と、正式な発注を受けた段階を別の状態として扱うのかを決めます。
| 設計項目 | 決める内容 | 判断の目安 |
|---|---|---|
| 受注確定条件 | 何が揃えば受注として扱うか | 条件を満たした後に販売管理へ渡す |
| 連携対象 | 顧客、商品、数量、金額、納品条件など | 後工程で入力し直す項目を優先する |
| 正となるシステム | 顧客・商品・請求などの確定情報の管理先 | 更新担当と更新場所が明確な側を正とする |
| エラー時の対応 | 通知先、再処理、手動復旧の担当 | 原因と対応状況を記録し、未処理を残さない |
CRMでは商談ステージを使って営業プロセスを管理できます。各ステージの意味と移行条件を定め、受注ステージに進める前に必要項目を確認する設計が、引き継ぎの質を左右します。営業担当者が何を確認すべきかを項目に反映すれば、新人への業務説明にも役立ちます。
たとえば、正式な発注の受領を条件とするなら、その確認状況を記録する項目と、確認する担当者を決めます。納品条件の確定も必要なら、どの情報が未確定のときに受注ステージへ進めないのかを共有します。
顧客と商品データの正を決める
CRMと販売管理の両方で顧客情報を自由に更新すると、住所や担当者名の差異が積み重なることがあります。顧客情報をどちらで更新するか、相手側にはどの識別子を渡すかを決めます。商品名と商品コードも同様に、双方で同じ意味を指す対応関係を整理します。
既に管理している項目で必要な情報を表せるか確認してから、追加の項目を設計します。
- 顧客ID ── 連携先にも保持されていれば、名称の表記が異なる場合でも同じ顧客かを照合する手がかりになります。
- 商品コードと提供単位 ── 対応づけることで、同じ名称でも異なる商品を誤って扱わないようにします。
- コードの発行・変更 ── どちらのシステムで行うか、変更を相手側へ反映する担当は誰かも決めておきます。
必要な項目を網羅しようとして入力欄を増やしすぎると、更新されない情報が残りやすくなります。初期の連携項目は、次の分類で選びます。
- 受注を特定する情報
- 後工程で処理する情報
- 処理結果を営業が確認するための情報
各項目について、入力元、更新する担当、連携先での用途を確認し、使い道が定まらない項目は初期対象から外します。運用中に不足が判明した項目は、どの業務判断に必要かを確認して追加します。
受注情報を連携し、後工程で使える状態にする
受注連携では、顧客名だけでなく、担当者、商品・サービス、数量、単価、合計金額、納品希望日、納品先、支払い条件など、後工程が必要とする情報を整理します。どの項目がCRM由来で、どの項目を販売管理側で補完するかも明確にします。
例えば、CRMで商品と数量を登録していても、販売管理で請求条件を確定する運用なら、請求条件の入力担当と確定タイミングを別に定義します。
連携方法には、次の二通りがあります。
- イベント時の連携 ── 受注ステージへの移行をきっかけにデータを送ります。即時の業務処理が必要なら候補にします。
- 定期処理 ── 一定の間隔で対象レコードをまとめて処理します。まとめて処理できるなら検討します。
実際の方法は、利用する製品や連携手段が対応している条件に合わせて決めます。方法を選ぶ際は、対象レコードの抽出条件、必須項目が不足した場合の扱い、送信後に結果を確認する場所も合わせて整理します。
納品・請求・入金の状態を営業へ戻す
販売管理に蓄積された受注後の情報は、次の営業対応にも使えます。例えば、購入履歴を見て継続提案の時期を検討したり、入金状況に応じて顧客フォローの担当を決めたりできます。
すべての販売情報をCRMへ戻す必要はありません。営業が次の行動を決めるために必要な状態を選び、顧客や取引レコードと紐づけます。受注から納品、請求、入金までの情報が必要な範囲でつながると、商談の履歴と顧客の取引状況をあわせて参照できます。
- 更新元と更新の契機 ── 戻す情報を決めるときに、あわせて定めます。
- 決めておく内容 ── 納品状況が変わった時点でCRMを更新するのか、定期的に最新状態を同期するのか。
- 曖昧な場合のリスク ── 営業が古い情報を見て判断する可能性があります。
HubSpotの取引管理は、受注前の営業フローを可視化します
HubSpotを連携設計に使う場合、取引レコードを営業プロセスのどこに置くかを先に決めます。
取引を作成してステージを管理するだけでは、受注後の販売管理まで自動的につながるわけではありません。
取引の情報を受注時の引き継ぎに活用し、販売管理や会計へ何を渡すかを設計します。HubSpot側で管理する商談情報と、販売管理側で確定する受注情報を分けておけば、営業が更新する項目とバックオフィスが更新する項目を整理できます。
HubSpotの取引には、現在のステージでの滞在時間が担当者の成約済み取引の平均より20％長くなった時点を記録する標準項目があります出典。
取引ステージを実際の営業プロセスに合わせる
取引ステージは、商談がどの段階にあるかを示します。ステージを細かく増やすより、営業上の判断や受注見込みが変化する節目を基準に設計します。各ステージの定義を共有し、担当者によって同じ状態の解釈が変わらないようにします。
例えば、次のように営業活動で意味のある区切りを置きます。
- 提案を行った段階
- 見積を提示した段階
- 受注条件の合意を確認した段階
ステージごとに必要な情報を定めると、案件の進行状況を説明しやすくなります。ステージを追加・変更する場合は、既存の取引をどの状態に当てはめるか、移行の判断を誰が行うかも整理します。
名前だけ変えて運用を始めると、担当者ごとに以前の定義が残ることがあるため、定義と更新方法を一緒に共有します。
受注確度と必須項目を運用に結びつける
受注確度や必須項目は、営業の判断材料と引き継ぎ条件に合わせて設計します。
- 受注確度 ── 担当者の感覚だけで値を付けるのではなく、顧客の意思決定状況や合意内容など、判断の根拠を説明できる情報と結びつけます。
- 必須項目 ── 次の判断や引き継ぎに使う情報に絞ります。
根拠が記録されていれば、案件の見込みを確認するときに、確度の数字だけを見て判断することを避けやすくなります。
必須項目の例として、受注時に受注理由を記録し、見積提示時に金額や予定日を確認する設計が考えられます。入力欄が多すぎる場合は、更新されない項目を確認し、業務で使っているものだけを残します。
取引ボードで商談の状態を確認する
次の画面は、取引をステージごとに並べたボード表示です。
ボード表示では、各商談がどのステージに置かれているかを一覧で把握できます。ステージ名が実際の業務判断と結びついていると、滞留している商談や次の確認が必要な案件を見つける手がかりになります。
- ステージ以外の確認先 ── 次の対応予定や必要項目の入力状況も取引レコードで確認します。
- ボードとレコードの一致 ── 揃っていれば、営業内の確認から受注後の引き継ぎへつなげやすくなります。
営業から販売管理へ渡す条件を定める
HubSpot上で受注になった取引を、どの条件で販売管理へ渡すかを決めます。ステージ変更だけを条件にするのか、発注情報や納品条件などの必須項目も揃った場合にするのかを整理します。
条件が曖昧なまま自動化すると、不足情報を含むデータが後工程に渡ることがあります。受注確定の定義、連携対象の項目、必須項目の入力元を先に揃えたうえで、販売管理側で対象取引を特定し、受注登録に必要な情報を読み取れるか確認します。
登録後は、次の点も確かめます。
- 取引の照合 ── CRM側の取引と販売管理側の受注が同じ取引として照合できること
- 失敗時の対応 ── 失敗した取引を担当者が見つけて対応できること
これらを対象業務で確認してから、連携範囲を広げます。
HubSpotで受注を販売管理へ渡す設定の具体例
ここまでの設計を、HubSpotの設定に置き換えます。メニュー名は公式ナレッジで確認した内容です。画面の表示は更新されるため、設定前に最新の公式ナレッジを確認してください。
受注ステージに必須項目を設定する手順
受注の定義を「発注の受領を確認できたこと」とするなら、その確認が記録されていない取引を受注にできないようにします。公式ナレッジでは、これを条件付きステージプロパティ（オブジェクトパイプラインの設定と管理）と呼びます。
- 必須にしたい項目を先に作ります。例：「発注番号」「請求先名」「支払い条件」「納品希望日」。読み取り専用のプロパティは使えません。
- 設定（歯車）＞データ管理＞オブジェクト＞取引＞「パイプライン」で対象のパイプラインを開き、「受注」ステージの行の「条件付きロジックルール」列で「ルールを追加」を押します。
- 条件を「取引ステージ」が「受注」である、とし、「依存プロパティ」に上の項目を追加して「必須」にチェックを入れます。
- 「ロジックを保存」を押し、テスト用の取引を受注に動かして、未入力のときに進めないことを確認します。
- 受注ステージの取引確度を100%にし、失注ステージは0%に設定します。レポートが取引を正しく集計します。
| 受注時に必須にする項目（例） | 販売管理側で使う場面 | 入力元 |
|---|---|---|
| 発注番号 | 受注登録と請求書の照合 | 営業（顧客の発注書から転記） |
| 請求先名・請求先メール | 請求書の宛先 | 営業。確定は営業事務 |
| 支払い条件 | 請求日・入金予定日の算出 | 営業。確定は経理 |
| 納品希望日 | 納品スケジュールの作成 | 営業 |
| 商品項目（数量・単価） | 受注明細の作成 | 営業（取引の商品項目） |
項目が多すぎると入力が止まるため、販売管理が受注登録に必ず使うものだけに絞ります。
受注をきっかけにワークフローで担当者へ渡す手順
- 「オートメーション」＞「ワークフロー」で「ワークフローを作成」を押し、対象を「取引」にします（利用はProfessionalまたはEnterprise。公式ナレッジ「Create workflows」）。
- 「取引の登録条件を設定」から「イベントが発生したとき」を選び、「プロパティ値が変更された」で、プロパティを「取引ステージ」、値を「受注」にします。
- アクションに、営業事務への「タスクの作成」を入れ、件名に取引名と発注番号を含めます。外部のシステムへ送る場合は、アクション「Webhookを送信」（Data HubのProfessionalまたはEnterprise。メソッドはPOSTまたはGET、URLはHTTPSで始まる）を使います。
- テスト用の取引を受注に動かして、タスクの作成と、受信側でのデータの到着を確認します。
イベントの登録条件は、ワークフローをオンにした後の変更だけが対象です（イベントの登録条件を設定する）。既存の受注済みの取引を含めたい場合は、フィルターによる登録条件か、手動の登録を使います。また、再登録は初期状態ではオフです。差し戻した取引を再度受注にした場合の扱いも、先に決めてください。
販売管理への連携方式を選ぶ判断表
| 状況 | 最初に試す方式 | 確認すること |
|---|---|---|
| 受注件数が少なく、項目も限られる | ワークフローのタスク作成と、取引のエクスポート（CSV） | 入力元と更新担当者、取り込み時の項目の対応 |
| 受注の都度、自社の販売管理システムへ送りたい | ワークフローの「Webhookを送信」、または非公開アプリのAPI | 失敗時の通知先、二重登録の防止（取引IDでの照合） |
| 既存のSaaSどうしをノーコードでつなぎたい | iPaaS | 対応するトリガー、実行回数、処理の遅延 |
| 請求・会計までHubSpotの取引から進めたい | 会計向けの連携アプリ | 見積・請求・入金状況のどこまでを連携するか |
freeeを使っている場合は、StartLinkが開発するSync for freeeで、HubSpotの会社をfreeeの取引先として作成し、取引から見積書・請求書を作成し、受注した取引をfreeeの取引として登録できます。freeeでの入金状況は、定期処理でHubSpot側に反映されます。標準の連携で足りない受注後の流れを、取引レコードの画面から進めるための連携アプリです。会計ソフトとの連携の選び方はfreeeと連携できるCRMの選び方でも整理しています。
StartLinkのHubSpot導入・構築支援では、現状の整理・要件定義、設計・構築、データ移行、テスト・検証、定着・運用改善の順に進め、HubSpotゴールドパートナーとして150社以上のHubSpot支援に携わってきた中でも、受注の定義と必須項目を先に決めた案件のほうが、後工程の手戻りが少ないと考えています。連携は受注情報の引き継ぎ1つから小さく始めます。詳しくはHubSpot導入・構築支援をご覧ください。ワークフローの登録条件や再登録の決め方はHubSpotワークフロー設計書の書き方で解説しています。
連携は、共通データ・タイミング・例外対応を段階的に整えます
CRMと販売管理の連携は、システム同士を接続した時点で完成するものではありません。データ項目の定義、更新のタイミング、失敗したときの対応を業務に合わせて設計します。
全領域を一度に変えるのではなく、受注情報の引き継ぎから始め、必要な範囲を段階的に広げます。
- 届いたか ── 想定した情報が届いたか
- 処理できたか ── 担当者が処理できたか
- 照合できたか ── 処理結果を照合できたか
段階ごとにこれらを確認すると、次に広げる範囲を判断しやすくなります。
共通項目とデータの意味を合わせる
顧客名、商品名、金額など、双方で使う項目を洗い出します。項目名が同じでも、税抜か税込か、見積時点か確定時点かなどの意味が異なる場合があります。単位、入力形式、更新責任者を含めて定義を揃えます。
| 項目 | すり合わせる内容 |
|---|---|
| 顧客 | 顧客ID、正式名称、住所、担当者 |
| 商品 | 商品コード、商品名、提供単位 |
| 金額 | 税区分、値引き、端数処理、確定時点 |
| 日付 | 受注日、納品希望日、請求日 |
| 状態 | 受注、納品、請求、入金の定義 |
特に金額は、見積額と請求額が同じ意味とは限りません。CRMでは商談の見込み額、販売管理では受注や請求の確定額を管理するなど、用途ごとの違いを明記します。
連携項目の一覧には、各項目の意味だけでなく、入力元、更新責任者、連携先での使い道、値が変わった場合の扱いも記録します。定義が異なる項目は、同じ名前のまま送らず、どの値を渡すかを業務担当者間で確認します。
連携のタイミングを業務要件で選ぶ
受注と同時に後工程を始める必要がある業務では、受注確定をきっかけに連携する方法が候補になります。一定の時間内にまとめて処理できる業務では、定期的な連携が適する場合があります。
受注後の納品や請求について、どのデータが確定したら後工程を始めるかを先に決めます。確定のたびに処理が必要ならイベント連携、まとめて処理できるなら定期連携を候補にします。各候補は、次の項目を同じ基準で比べます。
- 処理の開始条件
- 許容できる遅延
- 連携先が処理できる頻度
あわせて、抽出漏れや重複送信の見つけ方と、遅延時に業務への影響を判断する担当者を決めます。ただし、接続方法や連携先の条件によって希望する頻度で処理できない場合があるため、対応範囲を候補ごとに確認します。
エラーを検知して、未処理を追えるようにする
連携に失敗したとき、誰がどの画面やログを確認し、どの条件で再処理するかを決めます。エラーをメールやチャットで知らせる場合も、通知先と対応担当をセットにします。通知だけで完了とせず、再処理後に販売管理側で受注情報が作成されたかを確認します。
連携ログでは、対象レコード、失敗理由、対応状況を記録します。再処理で二重登録が起きる可能性がある場合は、顧客IDや取引IDなどの照合方法を先に決めます。手動対応が必要な項目が明らかになったら、手順として残して担当者間で共有します。
運用手順には、次の内容を含めます。
- エラーの確認場所
- 記録する内容
- 再処理の実施者
- 完了を判断する方法
再処理できない場合の連絡先や、手動で処理した取引を連携済みとして記録する方法も定めておくと、同じ取引が後から再送される事態を防ぎやすくなります。
定期確認で連携品質を整える
運用開始後は、CRMの受注件数と販売管理の受注件数、顧客ID、金額などを照合します。差が見つかった場合は、次のどれに当たるかを切り分けます。
- 項目定義のずれ
- 連携失敗
- 更新タイミングの違い
件数の差だけで処理状況を判断せず、該当する取引を特定して、どちらのシステムで何が登録・更新されたかを確認します。
確認する項目と頻度は、業務の処理周期に合わせて定めます。日々受注を処理する場合は未連携データを日次で確認し、月次で締める項目は締め処理時に元データと連携先を照合します。
次の表は、照合する項目と頻度を決めるための例です。自社の処理周期に合わせて置き換えてください。
| 照合する項目 | 頻度の例 | 差が出たときの切り分け |
|---|---|---|
| 受注件数（CRMの受注取引と販売管理の受注） | 日次 | 連携の失敗か、登録のタイミングの違いか |
| 顧客ID・正式名称 | 週次 | 項目定義のずれか、片方だけの更新か |
| 受注金額（税区分を揃えて比較） | 月次の締め処理時 | 税区分・値引き・端数処理の定義の違いか |
| 未処理（エラー）の取引 | 日次 | 再処理で解消できるか、手動対応が必要か |
差が見つかったら、対象の取引、差の内容、原因、対応担当、解消状況を記録します。未解消の差は次回の確認時に追跡し、同じ差が繰り返される場合は項目定義、連携条件、更新手順を確認します。
ただし、担当者が継続して確認・対応できない頻度では運用しにくいため、確認表や通知の対象を見直します。
自社に合う連携は、受注後の業務から小さく始めます
連携の設計は、利用するツールを先に決めるより、営業からバックオフィスへ引き継ぐ業務を整理するところから始めます。受注の定義と必要なデータが揃えば、実装方法を比較しやすくなります。
まず一つの業務の流れで連携を確かめ、運用できる形に整えてから対象を広げます。
対象を選ぶ際は、転記や確認が発生している業務を挙げ、連携によってどの作業を減らすのか、どの状態を関係者が確認できるようにするのかを明確にします。
HubSpotのワークフローでは、CRMレコードのプロパティ1項目の値が別の値に変わったことを条件にできます。出典。
現状の手作業を業務フローとして書き出す
受注が決まってから納品、請求、入金まで、誰がどの情報をどこへ入力しているかを並べます。メールや表計算による連絡、同じ内容の再入力、確認に使う資料も含めると、連携が必要な場所を見つけやすくなります。
担当者個人の手順に依存している箇所は、引き継ぎ後に誰が何を確認すればよいかを決めます。情報を集める段階では、すべての作業を自動化対象にする必要はありません。まず重複入力や受注後の確認など、具体的な課題がある箇所を選びます。
業務の各段階について、次の内容を記録します。
- 開始条件
- 入力する情報
- 処理担当
- 完了の判断方法
これにより、連携したいのがデータの受け渡しなのか、承認や確認の手順なのかを区別できます。
一つの受注フローでデータを確かめる
最初の対象では、受注条件、連携項目、正となるシステム、エラー時の担当を明確にします。そのうえで、受注情報が販売管理へ渡り、後工程が必要とする情報を確認できるかを確かめます。
想定する取引の入力から販売管理での確認までを一続きでたどり、必須項目が不足した場合や値に差がある場合の扱いも確認します。
- 不足があった場合 ── 受注定義や入力項目を見直します。
- 処理が止まった場合 ── 担当者が自力で原因を追えるか、再処理後に二重登録が生じないかを確認します。
- 広げる判断 ── 連携が成功したかだけでなく、担当者が例外を処理できたか、照合で差を見つけられたかも確認します。
小さな範囲で運用を見直してから、対象の業務や連携する情報を広げます。
CRM・販売管理・会計の役割をつなげる
受注後の業務が整理できたら、請求や仕訳、入金消込を含めた流れを確認します。CRMで商談を管理し、販売管理で受注と請求を扱い、会計で入金や仕訳を扱う場合、各システムの確定情報と連携タイミングを明確にします。
一気通貫の設計は、すべてを同じシステムに集約することとは限りません。どのシステムで何を管理するかを定め、顧客や取引の識別情報を使って必要なデータを受け渡します。業務の規模や商品、取引条件に応じて、段階ごとに整えるのが現実的です。
例えば、請求情報が販売管理で確定し、会計側で入金を扱う場合は、次の二点を決めます。
- 請求の確定内容を会計へ渡すタイミング
- 入金結果を照合する情報
システム間で同じ項目を更新する場合は、更新元と反映先を明確にして、確定情報が複数に分かれないようにします。
よくある質問
CRMと販売管理の一方だけで運用できますか？
扱う業務の範囲によります。商談の管理が中心で、受注後の業務が別の仕組みで問題なく処理できるなら、CRMだけで営業管理を行えます。納品、請求、入金や在庫まで扱うなら、その業務を管理する仕組みと役割を整理します。
CRMの受注ステージを変えたら、販売管理へ自動連携できますか？
HubSpotでは、ワークフローの登録条件を「取引ステージが受注に変更された」とし、タスクの作成や「Webhookを送信」アクション（Data HubのProfessionalまたはEnterprise）で外部へ渡す方法があります。ただし、連携先の販売管理が受信できる条件や、必須項目の充足、重複登録の防止、失敗時の担当を設計する必要があります。受注ステージに条件付きステージプロパティで必須項目を設定し、テスト用の取引で動作を確認してから対象業務に広げてください。
連携で最初に揃える項目は何ですか？
受注後の処理に必要な顧客、商品、数量、金額、納品条件などから始めます。顧客IDや商品コードのような識別情報と、金額の税区分や確定時点も合わせて定義します。後工程が使わない項目は初期対象から外し、必要性が確認できた段階で追加します。
CRMに受注後の情報を戻す必要はありますか？
営業が次の行動を決めるために役立つ情報は、CRMへ戻すことを検討できます。例えば、購入履歴、納品状況、請求・入金の状態などから必要なものを選びます。情報を増やしすぎると確認しにくくなるため、営業活動で参照する項目を明確にします。あわせて、販売管理のどの情報を正とするか、CRM側にいつ反映するかも決めておきます。
連携に失敗した場合はどう運用すればよいですか？
エラーの通知先、対応担当、再処理の条件、二重登録の確認方法を決めます。対応後は連携先にレコードが作成されたかを照合し、未処理が残っていないことを確認します。失敗理由と対応を記録し、繰り返し起きる原因は項目定義や連携条件の見直しにつなげます。手動で対応した取引も記録し、後から自動連携で重複処理されない状態にします。
まとめ
CRMは顧客や商談を受注前から管理し、販売管理は受注後の納品・請求・入金を支えます。両者をつなぐときは、受注の確定条件、顧客や商品データの正、連携タイミング、エラー時の対応を先に整理します。
まずは受注から販売管理への引き継ぎを一つ選び、次の手順で確認します。
- 現在の受注後フローと、手作業で転記している情報を書き出します。
- 受注の定義と、連携に必要な顧客・商品・金額の項目を決めます。
- 小さな範囲で連携と例外対応を確かめ、運用できたものから広げます。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
- 販売管理とは？業務フロー・システム化のメリット・選び方を基礎から解説
- CRM × 販売管理 × 会計の統合設計｜営業→受注→請求→入金→仕訳を一気通貫でつなぐ方法
- SFA導入の失敗事例7選｜なぜ定着しないのか原因と回避策を徹底解説
- Quote-to-Cash（見積から入金まで）とは？業務フロー全体の設計と自動化のポイント
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
