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