こんな課題ありませんか
- 資料請求や問い合わせの数は増えたのに、商談の数がほとんど変わっていない
- 問い合わせを営業に渡したあと、いつ誰がどこまで追ったのかが分からない
- 営業に渡す基準が人によって違い、渡す・渡さないで毎回もめる
- 商談化率も受注率も見ていない。数字は担当者の感覚しかない
- HubSpot は入れたが、問い合わせが来たあとに何が起きるかを決めていない
- 一度商談にならなかった相手に、その後どう接触すればいいのかが決まっていない
humbulls の特徴
humbulls が引き受けるのは、営業に渡す条件の合意と、HubSpot 上の仕組みと、見る数字までです。人員の配置や評価制度の設計は範囲に含みません。
渡す条件を、営業と合意した1枚にします
ツールの設定より先に、言葉を合わせます。どの状態になったら営業に渡すのか、渡したあと何日で何をするのか、渡さないと決めた相手はどこに置くのか。これをその会社で実際に使われている言葉で1枚に書き、営業側の合意を取ってから設定に入ります。順番を逆にすると、ステージだけが増えて、誰も同じ意味で使っていない項目が残ります。
追客と差し戻しを、担当者の記憶ではなく HubSpot に置きます
問い合わせが入ってからの割り当て、期限つきのタスク、通知、初回接触の記録、商談にならなかった相手の戻し先までを、HubSpot の設定として組みます。合意した1枚を書いた人が、そのまま設定を作り、手順書まで書きます。HubSpot の設計と実装そのものは、他ツールからの移行や運用ルールの策定を含めて humbulls が手を動かしてきた範囲です。工程を分業しないので、設計と実装の間で引き継ぎが挟まりません。引き継ぎの設計を外に出したのに、その外注先の中で引き継ぎが起きている、という状態を作らないためです。
見る数字を、問い合わせ数から商談化率と受注率まで伸ばします
問い合わせの数で止めず、どの経路から来た人が商談になり、受注に至ったかを1つの画面で追える状態にします。打ち手はその画面を見てから決めます。数字を作る手順は AI スキル（.md ファイル）として渡すので、翌月からは社内で同じ形に作り直せます。humbulls は自社サイトの月次レポートをこの形で運用していて、レポートの再生産はスキルの実行1回で終わります。
引き継ぎが切れる4パターン
問い合わせの数が増えても商談が増えないとき、原因は集客側にないことがあります。渡すところで止まっているからです。止まる場所は、マーケティングからインサイドセールス、インサイドセールスから営業へ向かう線の上に4つあります。
パターン1 定義が違う
MQL・SQL という語を導入すれば、渡す基準は揃うと考えられています。ツールにはライフサイクルステージという項目が最初から用意されているので、そこに人を流し込めば定義が共有された気になります。用語を統一することが、認識を統一することだと扱われています。
ステージの名前は定義ではありません。「見込みあり」という同じ名前の欄に、マーケティング側は資料をダウンロードした人を入れ、営業側は予算と時期が決まっている人を想定しています。名前が同じなので、食い違いに気づく機会がありません。会議で「渡したのに動いてくれない」「渡ってくるのが早すぎる」という言い合いが起きるとき、対立しているように見えるのは姿勢ですが、実際にずれているのは語彙です。もう1つ、MQL・SQL は分業を前提にした英語圏の語です。日本の会社では営業部の中の営業企画が長くマーケティング機能を担ってきたので、その語を持ち込んだ瞬間に、現場が普段使っている言い方と切れることがあります。用語を入れたのに会話が噛み合わなくなるのは、そのためです。
ステージ名を決める前に、条件文を書きます。「この3つを満たしたら営業に渡す」を、その会社で既に通じている言葉で1枚にして、営業側の合意を取ってから HubSpot のライフサイクルステージとプロパティに落とします。MQL・SQL という語は、社内で既に通じている場合だけ使います。通じていないなら使いません。翻訳した用語を先に配ると、定義の議論が用語の議論にすり替わります。
パターン2 タイミングが遅い
追いかけるのが遅いのは人手が足りないからだ、と考えられています。だからインサイドセールスの担当を置く、あるいは増やす、という順番で話が進みます。速さは人数で買えるものとして扱われています。
遅れの原因は、人数よりも経路にあることがあります。フォームの通知が代表アドレスに入って埋もれる。担当の割り当てが手作業で、朝会まで動かない。休み明けにまとめて処理される。担当を1人増やしても、通知が埋もれる構造はそのまま残ります。そして、問い合わせから最初の接触までに何時間かかっているかを記録していない会社があります。記録していない数字は、人を増やしたあとで良くなったのかどうかも判定できません。
先に、問い合わせから最初の接触までの時間を記録する場所を作ります。HubSpot 側では、フォーム送信をきっかけに担当を自動で割り当て、期限つきのタスクと通知を同時に出し、初回接触の日時をプロパティに残します。そのうえで自動化の本数を絞ります。HubSpot Starter ではワークフローが25個までで、思いついた通知を足していくと枠がすぐ埋まり、あとから必要になった自動化が入りません。25の枠のうち何本を追客に使うかを、最初に決めます。人を置くかどうかの判断は、時間が測れるようになってからにします。
パターン3 情報が渡らない
営業に渡す情報は多いほど親切だ、と考えられています。行動履歴もスコアも全部見えるようにしておけば、あとは営業が判断できるはずだ、という前提です。逆に「名前と会社名とメールアドレスがあれば、残りは電話で聞けばいい」と割り切っている会社もあります。
最初の接触で実際に使われるのは数項目です。どの資料を落としたか。どのページを見て問い合わせたか。以前に接点があったか。誰の紹介か。行動履歴が延々と並んでいる画面は、電話をかける直前には読まれません。読まれないので、結局ゼロから聞き直しになります。ここで失われているのは、相手が同じ話を2回する時間です。項目を増やす側にも副作用があります。フォームの入力欄を増やすと問い合わせが減り、営業側の入力項目を増やすと空欄が並びます。埋まっていない欄が多い画面は、埋まっている欄も信用されなくなります。
最初の接触で使う項目を5つ前後に絞り、レコードを開いた最初の画面に出します。フォームの入力欄、HubSpot のプロパティ、営業が見る画面の並びを、1本の対応表にして設計します。スコアリングは最初に作りません。点数は、渡す・渡さないの判断が言葉で書けたあとで、その判断を機械に写すための道具です。言葉が決まっていない段階で点数から始めると、なぜその点数なのかを誰も説明できない状態が残り、営業は結局その点数を見なくなります。
パターン4 戻す経路がない
商談にならなかった相手は失注で、マーケティング側の数字からは外れる。そのあと追いかけるかどうかは営業の判断だ、と考えられています。だから CRM 上では「対応済み」で閉じられます。
商談にならなかった相手には、断った人と、今は時期ではないだけの人が混ざっています。予算の時期が違う、担当が代わったばかり、比較検討がまだ始まっていない。ところが閉じられたレコードは、そのまま開かれずに残ります。さらに、断られた理由が言葉で残らないので、マーケティング側は同じ層を同じ方法でもう一度集めにいきます。渡した先の情報が戻ってこない会社は、打ち手が「リードの数を増やす」しか残らなくなります。人を増やしても、増えた人が同じ場所で同じように詰まります。
商談にならなかった相手の行き先を、設計の最初に作ります。「今ではない」を独立したステージとして持ち、理由と再接触の時期をプロパティに残し、時期が来たらマーケティング側のリストへ自動で戻します。あわせて、週に1回30分、マーケティング側と営業側が同じ画面を見る場を作ります。見るのは、渡した件数、商談になった件数、ならなかった理由の上位3つ。この場がないと、合意した定義は数ヶ月で形骸化します。追わないと決めた相手についても、決めた記録を残します。全件を追い続ける前提で設計すると、結局どれも中途半端に触られて、誰も状況を把握していない一覧が残ります。
進め方
実際の進め方は前提を確認したうえで相談して決めますが、基本の形は次の5ステップです。
現状の棚卸し
問い合わせが入ってから受注までの流れを、いま実際に起きているとおりに書き出します。誰が何をしているか、CRM に何が入っていて何が入っていないか、渡す基準が言葉になっているかを確認します。書き出すのは、直近3ヶ月に実際に起きたことです。この工程を省くと、あとから「その運用はもう変わっている」という話が出て、作った定義がその時点で古くなります。
- 主な成果物: 現状の流れの整理／止まっている場所の一覧
渡す条件の定義と合意
営業に渡す条件、渡したあとの動き、渡さないと決めた相手の置き場所を1枚にします。営業側の担当者と同じ場で読み合わせ、言葉を直してから合意します。ここが一番時間のかかる工程です。長さを決めるのは、相手の社内で意思決定が動く速さです。合意を取らずに設定へ進むと、稼働した翌週から例外運用が始まります。
- 主な成果物: 渡す条件の1枚（条件・例外・渡さない場合の行き先）
HubSpot への実装
合意した内容を、ライフサイクルステージ、プロパティ、担当の自動割り当て、期限つきタスク、通知、差し戻しの経路として設定します。ワークフローの本数は先に配分を決めてから作ります。HubSpot Starter では25個が上限なので、あとから必要になる自動化のために枠を残します。設定は、定義を書いた人がそのまま作ります。
- 主な成果物: 稼働するパイプラインと自動化設定（顧客名義）／設定内容の一覧
計測と会議体の設置
商談化率と受注率が1つの画面で見える状態にして、週に1回30分、渡した件数・商談になった件数・ならなかった理由を見る場を作ります。最初の2回は humbulls が進行して、3回目からは社内で回してもらいます。会議体まで作らないと、定義は形骸化します。数字だけ見える状態にしても、直す判断をする場がないと使われません。
- 主な成果物: 商談化率・受注率のダッシュボード／週次レビューの型（見る数字・議題・記録の残し方）
定着と引き渡し
運用の手順を文書にして渡します。繰り返す作業は AI スキル（.md ファイル）にして、引き渡しの場で一度実行してもらいます。定義を見直すタイミングと、見直すときに誰が集まるかも同じ紙に書きます。ここで humbulls の関与は終わります。続けて関与する場合は、この時点で改めて範囲を決めます。
- 主な成果物: 運用手順書／AI スキル（.md）／定義の見直し手順
成果物
進め方の各ステップで、次のものが手元に残ります。
| # | 成果物 | 中身 |
|---|---|---|
| 1 | 現状の流れの整理 | いま実際に起きている流れと、止まっている場所の一覧 |
| 2 | 渡す条件の1枚 | 営業に渡す条件、例外、渡さない場合の行き先 |
| 3 | 稼働する HubSpot の設定 | ステージ、プロパティ、自動割り当て、タスク、通知、差し戻し経路 |
| 4 | 項目の対応表 | フォーム項目 → プロパティ → 営業が最初に見る画面 |
| 5 | 商談化率・受注率のダッシュボード | 経路別に、商談になった件数と受注した件数 |
| 6 | 運用手順書と AI スキル（.md） | 次回から社内で回すための手順と、繰り返す作業の自動実行 |
無料相談
相談は60分。問い合わせが足りないのか、渡した後で止まっているのか、そもそも渡す基準がないのかを、その場で切り分けます。売り込みはしません。フォームからのご連絡には3営業日以内に返信します。
関連ナレッジ
引き渡しの設計と HubSpot 上の実装で humbulls が実際に使っている手順は、記事で公開しています。
- MQL・SQL の定義と基準 — HubSpot ライフサイクルステージで実装する
- HubSpot ライフサイクルステージ運用 — 定義設計から自動更新までの実務
- 商談議事録の AI 分析 — 失注理由の傾向を月次で自動集計する方法
記事のとおりに試して詰まったところから相談できます。
実績・事例
引き継ぎ設計の事例として掲載できるものは、現時点ではありません。
隣接する領域（他ツールからの HubSpot 移行、外部からの HubSpot 設計、大規模データの運用ルール策定）は担当していますが、CRM・MA の構築としての記録しか残っておらず、引き継ぎ設計としての記述がないためです。社名・時期・数字・成果と掲載の許諾が揃った案件から、順に掲載します。
FAQ・価格・完了後の道
費用の考え方
対象の範囲と、既に HubSpot が入っているかどうかで大きく変わるので一言では答えられませんが、考え方は先に出します。金額は、次の3工程のどこまでを含めるかで決まります。ヒアリングのあとにお見積もりし、予算が決まっている場合は、その範囲でできることを切り出して提案します。
| 工程 | 内容 |
|---|---|
| 現状の棚卸しと条件の合意 | 現状整理、止まっている場所の特定、渡す条件の1枚と合意 |
| HubSpot への実装 | ステージ・プロパティ・自動割り当て・タスク・通知・差し戻し経路 |
| 計測と引き渡し | ダッシュボード、週次レビューの型、運用手順書と AI スキル |
工程を切り出しての依頼も受けます。条件の合意までを一緒にやって、実装は社内で、という形でも構いません。
よくある質問
費用はどのくらいかかりますか。
範囲と、既に HubSpot が入っているかどうかで変わるため、一言では答えられません。工程ごとの内訳は上の「費用の考え方」に出しています。条件の合意までだけ、といった形での依頼も受けるので、予算が決まっている場合は先に伝えてください。その範囲でできることを切り出して提案します。
どのくらいの期間がかかりますか。
期間が決まる条件は、営業側との合意にどれだけ時間がかかるかです。この部分の長さは、社内で意思決定が動く速さに左右されます。
どのくらい前に相談すればよいですか。
相談そのものはいつでも受け付けます。ただし同時に進める案件数に上限を置いているので、着手時期は相談のタイミングで前後します。上限を決めているのは、1件あたりの手数を落とさないためです。
架電や商談の設定まで代行してもらえますか。
代行はしていません。humbulls が引き受けるのは、渡す条件の設計と、HubSpot 上の仕組みづくりと、社内で回せる状態にするところまでです。架電やアポイントの獲得を外部に任せたい場合は、その専門の会社を探すほうが早く、humbulls に依頼する意味も薄くなります。
HubSpot の Starter プランでもできますか。
条件つきで可能です。ライフサイクルステージ、プロパティ、フォーム、タスク、ワークフローによる自動化までは Starter の範囲で組めます。ただしワークフローは25個までなので、追客に何本使うかを先に決める設計が必要になります。それを超える運用が要るかどうかは、現状の棚卸しの段階で判断して、必要なら Professional への切り替えを提案します。上げなくていい場合は上げない提案をします。
インサイドセールスの担当者がいなくても始められますか。
始められます。人を置く前に、追いかける手順を HubSpot 上に定義して、自動化できるところを自動化します。そのうえで、それでも人が要る部分を決めます。ただし商談そのものは人がやる仕事なので、担当者ゼロで完結する形にはなりません。人を置く判断を、数字を見てからにするための順番です。
HubSpot の導入・整備を頼むのと、何が違いますか。
範囲が違います。HubSpot の導入・整備は、アカウント全体を業務に合わせて立ち上げる支援です。このメニューは、そのうち問い合わせから商談までの区間だけを対象にして、渡す条件の合意と会議体の設置まで含めます。既に HubSpot が入っていて、集客はできているのに商談が増えない、という状態の会社が対象です。まだ HubSpot が入っていない場合は、導入・整備のほうを先に提案します。
提案のために、いまの状態の診断を先に出してもらえますか。
提案書の作成のみの依頼は受けていません。営業の段階で出すのは、打ち合わせ、進め方の資料、見積書、概算スケジュールまでです。実際に画面を見て止まっている場所を特定するところからは、有償の範囲になります。
制作会社や代理店を経由しての依頼は可能ですか。
可能です。条件は1つで、実際に営業をしている担当者と humbulls が直接やりとりできることです。渡す条件の合意は、現場の言葉を聞かないと1枚に書けません。伝聞で受け取ると、合意したはずの定義が現場で使われないまま終わります。
AI をどこまで使いますか。顧客情報は学習に使われませんか。
定義の文案づくり、設定内容の点検、繰り返す作業の手順化に AI を使います。判断と合意は人が行います。データの扱いは要件に合わせて選べます。機密度が高い場合は、顧客データを AI に渡さず、AI にはコードを書かせ、データの処理はそのコードが実行する構成にします。この形では、AI が顧客データに触れる経路が設計として存在しません。
完了後の道
引き渡しでは、渡す条件の1枚、稼働している設定、運用手順書、AI スキルを渡します。定義を見直すタイミングと、そのとき誰が集まるかも同じ紙に書きます。
| 進む先 | どういうときに |
|---|---|
| 社内で回す | 渡した手順と AI スキルで、次から自社で運用と見直しを回すとき |
| HubSpot 導入・整備 | 問い合わせから商談までの外側も、アカウント全体として整えるとき |
| リード獲得支援 | 渡す仕組みが動いたうえで、母数そのものを増やす必要が出たとき |
| Growth Partner（伴走・月額30万円〜） | 定義の見直しと数字の確認を、継続して一緒に回す体制が要るとき |