「この値引きの条件表、HubSpotで自動化できますか」への答え

「この値引きの条件表、HubSpotで自動化できますか」

営業企画や経理の担当者から、スプレッドシートを1枚渡されることがあります。

商材ごと、数量ごと、契約プランごとに月額が違う。年度によって金額が改定されている。前払いならさらに割引がある。そういう条件表です。手作業で金額を計算しているので自動化したい、という依頼です。

ワークフローで組もうとして、最初の分岐を作ったところで気づきます。

条件が5つあると、組み合わせは掛け算で増えます。商材2種類、数量11段階、割引プラン2種類、契約年度2種類、前払いの有無で、176通り。分岐で表現するなら、176本の枝が必要です。

さらに厳しいのは、その後です。

• 翌年度の金額が決まると、ワークフローを開いて枝を足す
• 新しい割引プランができると、また枝を足す
• 数か月後、どこを直せばいいのか自分でも分からなくなる
• 担当者が変わると、誰も触れなくなる

「HubSpotでは無理そうなので、当面は手計算で」という結論になりがちな領域です。

ただ、これは作り方を変えると解決します。ワークフローの分岐は1本も使いません。

なぜ分岐で書くと破綻するのか

理由は、条件の数と分岐の数が比例していないことです。

条件が1つ増えるだけで、分岐は掛け算で増えます。上の例で割引プランをもう1種類（A・B・C）追加すると、88通りは132通りになります。増えるのは条件1つですが、作業量は44本の枝です。

そして分岐は、次の3点で保守に向きません。

• 変更履歴が追いにくい
  「いつ、誰が、どの金額を変えたか」がワークフローの編集履歴からは読み取りづらい
• テストが現実的でない
  88本の枝すべてを通す検証は、実務では行われません
• 更新できる人が限られる
  条件表を持っているのは営業企画ですが、ワークフローを編集できるのはHubSpot管理者です

条件表そのものは、営業企画が普段Excelで更新しています。その表を更新する行為が、そのままHubSpotに反映される形にできれば、この3点はすべて解消します。

考え方を反転させる：ロジックではなく、データとして持つ

やることは1つです。

条件表の1行を、HubSpotの1レコードにします。

「商材が定期便A、数量130、割引プランB、契約年度2026、前払いあり → 月額36,000円」という1行を、カスタムオブジェクトのレコードとして登録します。88通りなら88レコードです。

そして条件を1本の文字列（キー）にまとめます。

定期便A_130_B_2026_前払あり

親レコード（取引や契約など）の側でも同じ形式のキーを組み立てておけば、文字列が一致するマスタレコードを探して、その金額を持ってくるだけで済みます。

ワークフローの中身は2つのアクションだけです。

1. キーが一致するマスタレコードを関連付ける 2. そのマスタレコードの金額をコピーする 

分岐はゼロです。条件が何通りあっても変わりません。

レコードを増やすことをためらわない

「88レコードは多いのでは」と感じるかもしれません。ここは考え方を切り替えてください。

レコードはインポートで作ります。 88行のCSVを取り込むのに、10行と88行で手間の差はありません。翌年度分を追加するときも、既存の行をコピーして金額を直したCSVを1枚作るだけです。

一方で分岐は人が1本ずつ作ります。 ここに決定的な差があります。

レコード数を惜しまず、ロジックをゼロにする。

これがこの方式の要点です。

導入するとどう変わるか

運用面では、次のような変化が出ます。

適用根拠が記録として残る
どのマスタレコードが適用されたかを親レコードに書き込んでおけば、「なぜこの金額になったのか」を担当者が自分で確認できます。金額に関する問い合わせは、この一言が書かれているだけで減ります。

過去の取引に影響しない
マスタの金額を改定しても、すでに確定した取引の金額は変わりません（後述の「書き込み方式」による）。年度改定のたびに過去データが書き換わる心配がなくなります。

条件表とHubSpotがずれない
表を更新してインポートする運用にしておけば、二重管理が発生しません。

設計の4原則

手順に入る前に、以下の4つの原則を押さえておくと後で作り直しになりません。