HubSpotでの商談管理を進める中で、多くの担当者が突き当たる壁があります。
それは、「標準の『製品』機能では、自社の複雑なプランや契約形態を表現しきれない」という課題です。
一言でいえば、「HubSpotの決まった枠に業務を合わせるか(標準)」か、「業務に合わせてHubSpotの枠を作り替えるか(カスタム)」という選択の分岐点です。
本記事では、この二つの手法を徹底比較し、貴社のビジネスモデルに最適な選択肢を提示します。
1. 現場が直面する具体的な課題
HubSpotを導入してしばらく経つと、以下のような悩みが生まれることがあります。
- 「プランごとに独自の技術仕様や契約条件を管理したいが、標準の製品項目(ラインアイテム)では入力欄が足りない」
- 「将来的にプランの構成が変わる可能性が高く、標準機能のガチガチな制約が不安」
- 「見積書(Quotes)機能は使いたいが、データ分析のためにさらに細かい情報を紐付けたい」
これらの悩みを解決するためには、カスタムオブジェクトによる管理が有効です。
2. 徹底比較:標準製品 vs カスタムオブジェクト
| 比較項目 |
① 標準製品オブジェクト |
② カスタムオブジェクト |
| 基本構造 |
取引 ↔ ラインアイテム ↔ 製品 |
取引 ↔ 商談明細 ↔ プラン |
| データの柔軟性 |
△ 低い。 UI変更や複雑な関連付けに制限あり。 |
◎ 非常に高い。 独自プロパティを自由に持てる。 |
| 金額の計算 |
◎ 自動。 「数量×単価」が最初から動く。 |
△ 要設定。 計算プロパティ等の構築が必要。 |
| 過去データの保存 |
◎ 標準装備。 マスタ変更後も過去分は維持。 |
◯ 工夫で対応可。 ワークフローによる「コピー」または プランレコードの再作成で対応。
|
| 標準機能との連携 |
◎ 強い。 見積書や標準レポートにそのまま反映。 |
△ 弱い。 見積書反映には同期処理が必要。 |
3. 設定手順:① 標準製品オブジェクトの場合
「最短・最速」でHubSpotの機能をフル活用するための手順です。
ステップ1:製品マスタの登録
- 「ライブラリ」から「製品」を選択し、自社のサービスや商品を登録します。
- この際、標準の「単価」「頻度(月次・年次など)」を設定します。
ステップ2:必要に応じたカスタムプロパティーの追加
- 標準項目だけでは足りない場合、「製品」のプロパティーとして、独自の入力項目(例:導入支援メモなど)を追加します。
※製品プロパティーでは計算、ロールアップ、プロパティー同期が使用できないことに注意
ステップ3:取引への紐付け
- 各「取引」画面の右サイドバーにある「商品項目」から、登録した製品を選択します。
- これで自動的に「ラインアイテム(取引ごとの明細)」が生成され、合計金額が「取引の額」に反映されます。
4. 設定手順:② カスタムオブジェクトの場合
「分析・拡張性」を重視し、独自のビジネスモデルを構築する手順です。
ステップ1:カスタムオブジェクトの作成(Enterpriseプラン)
- 設定から「カスタムオブジェクト」を作成します(例:「プラン明細」と「プランマスタ」)。
- プラン明細オブジェクトを「プランマスタ」と「取引」の両方に関連付けられるようにします。
ステップ2:プロパティの設定
- プランオブジェクトに必要な項目を作成します。
- プラン明細オブジェクトに必要な項目を作成します。
- プラン金額(プロパティー同期もしくはプランオブジェクトからワークフローでコピー)
- 個数(数値)
- 合計金額(プラン金額×個数)
ステップ3:金額の固定化ワークフローの構築
中間オブジェクトは標準の「製品」と違い、マスタの値が変わると過去のデータも引きずられる可能性があります。これを防ぐ設定が重要です。
※プラン金額をプロパティー同期で実装している場合は金額が変わるたびにプランマスタレコードを作成し直す必要があります。
- ワークフローを作成:トリガーを「プラン明細オブジェクトの作成時」にします。
- アクション:プランマスタにある「現在の価格」を、プラン明細オブジェクトの「プラン金額(カスタム項目)」へコピーします。
- これにより、将来マスタの価格改定があっても、過去のレコードには影響が出ません。
ステップ4:合計金額の集計
- 「取引」オブジェクト側に「ロールアップ」プロパティーを作成し、「プラン明細」の「合計金額」を合計します。
5. どちらを選ぶべきかの最終判断
- 「標準製品オブジェクト」を選ぶべき人
- HubSpotの見積書発行機能(Quotes)をそのまま使いたい。
- 標準の売上分析レポートを即座に活用したい。
- 設定のメンテナンスコストを最小限に抑えたい。
- 「カスタムオブジェクト」を選ぶべき人
- プランの構成や属性が複雑で、将来的にさらなる変更が予見される。
- 「顧客」や「設置場所」など、他のオブジェクトと商品情報を密接に紐付けたい。
- データベースとして、より正確で詳細な構造を保持したい。
もし、構築の手間と天秤にかけても「将来的なデータの分析精度」や「複雑な関連付け」が優先されるのであれば、Enterpriseプランの強みを活かしたカスタムオブジェクト案が、長期的な資産となります。
一方で、シンプルなSaaSモデルであれば、標準機能を使い倒す方が現場の定着は早いでしょう。