IT企業のHubSpot活用｜受託開発・運用保守の商談から契約更新までを管理

「あのお客様の保守契約、更新はいつだったか」

「見積を出したまま、フォローが止まっている案件がいくつあるのか」

——受託開発やSIを手がけるIT企業では、こうした確認が営業担当者の記憶やExcelに頼りがちかなと思います。

IT受託・SIの営業管理をHubSpotで行うとは、引合から商談、受注、保守契約の更新までを、顧客ごとの1本の流れとして記録し、次にやるべきことが自動で見える状態をつくることです。一方で、開発の進捗や課題の管理は、HubSpotが得意とする領域ではありません。ここを最初に切り分けておくことが、設計の成否を分けると考えています。

この記事では、受託開発・運用保守を売る会社を想定して、HubSpotで管理するもの、管理しないものを順番に整理します。SaaSを自社提供する会社の話は別の記事（SaaS企業のHubSpot活用法）に譲り、ここでは「受託」と「保守契約」に絞ります。

• 新規開発と保守更新は、取引（案件）の流れが違う ── 同じ流れに載せると、更新の見落としが起きます
• 契約の終了日をプロパティーで持つと、更新を待たずに動ける ── ワークフローで担当者へ通知できます
• 開発の進捗・課題管理はHubSpotに入れない ── 専用のプロジェクト管理ツールに任せるほうが運用が続きます
• 顧客の窓口は複数いる ── 発注者・情報システム部門・決裁者を関連付けのラベルで区別します

IT受託・SIの営業管理で起きがちな3つの詰まり

受託開発の営業は、他業種と比べて「1件の商談が長く、受注後も関係が続く」という特徴があります。この特徴が、管理の詰まりを生みます。

引合の入口が複数あり、誰が持っているか分からない

紹介、Webからの問い合わせ、既存顧客からの追加相談、パートナー企業経由。受託開発の引合は入口が複数あります。入口ごとに担当者の手元で管理されていると、「同じ会社に別の担当者が別々に連絡していた」という二重対応が起きます。

会社（企業）レコードを軸にして、そこへ担当者とやり取りの履歴をぶら下げる構造にすると、誰が見ても同じ状況が把握できます。入口の違いは「リードソース」のようなプロパティーで持てば、後から経路別の受注傾向も見られます。

見積後に止まった案件が埋もれる

システム開発の見積は、要件のすり合わせで何度も修正されます。見積を出した後、顧客側の社内調整で数週間〜数ヶ月止まることも珍しくありません。この「止まっている案件」を見つける仕組みがないと、機会損失になります。

HubSpotでは、取引（Deal）にステージごとの滞在期間を見られる仕組みや、一定期間更新がない取引を一覧化するビューを作れます。「見積提示から30日動きがない取引」を毎週確認する運用を置くだけで、フォロー漏れはかなり減るかなと思います。

保守契約の更新が、人の記憶頼みになる

開発が終わると、運用保守の契約が始まります。この保守契約は年次更新であることが多く、更新の時期に見直し・増額の相談・終了の判断が入ります。更新日を営業担当者のカレンダーで管理していると、担当の異動や退職で一気に抜け落ちます。

更新は「放っておくと自動で続く」ように見えて、実は顧客と対話する数少ない機会です。ここを仕組みにするのが、次の章以降の中心です。

HubSpotでできること・専用システムに任せること

最初に線引きを表にします。HubSpotは営業・顧客対応の記録と自動化には強い一方で、開発現場の管理ツールではありません。

開発の進捗や課題の管理は、HubSpotでは扱わないほうがいいというのが当社の見方です。タスクを何十個も登録し、状態を日々更新する運用は、営業・CS向けに設計されたHubSpotの画面とは相性がよくありません。開発チームが普段使うプロジェクト管理ツールの中で完結させ、HubSpot側には「いつ納品予定か」「いま何フェーズか」程度の要約だけを持たせるのが現実的です。

なお、チケット機能は問い合わせの受付・担当割り当て・履歴の記録に使えます（使える機能の範囲は契約プランで変わります）。障害の原因を探る作業そのものは、HubSpotではなく監視やログのツールの役割です。

取引を「新規開発」と「保守更新」に分ける

受託・保守の管理で最初に決めたいのは、取引（Deal）の分け方です。

パイプラインを2本にする理由

新規開発の流れと、保守契約の更新の流れは、ステージが違います。新規開発なら「引合 → ヒアリング → 提案 → 見積提示 → 交渉 → 受注」、保守更新なら「更新時期の到来 → 内容確認 → 更新見積 → 合意 → 更新完了」といった具合です。

HubSpotでは、同じ取引でもパイプラインを分けられます。公式のナレッジでは、ステージが異なるプロセスがある場合に新しいパイプラインを作ることが推奨されています。カスタムパイプラインの作成にはStarter以上が必要で、チームごとの閲覧制限をかけるにはProfessional以上が必要です（出典: HubSpotナレッジベース「set up and customize pipelines」）。

2本に分ける利点は、レポートが混ざらないことです。新規開発の受注率と保守更新の継続率は、見るべき指標が違います。1本のパイプラインに混ぜると、どちらの数字も読みにくくなります。

保守更新の取引を自動で作る

更新の取引を担当者が手で作ると、作り忘れが起きます。会社レコードまたは受注済みの取引に「保守契約の終了日」の日付プロパティーを持たせ、終了日の一定日数前になったら更新取引を自動で作り、担当者にタスクを出す設計にします。

HubSpotのワークフローには「スケジュールに基づく」登録トリガーがあり、日付プロパティーを基準に「指定日」「指定日の前」「指定日の後」で動かせます。ただし、日付プロパティーを使う場合は「一度だけ」または「毎年」の実行に限られ、毎年の設定では日付の月日だけが参照され、年は無視されます（出典: HubSpotナレッジベース「Set ‘Based on a schedule’ workflow enrollment triggers」）。年次更新の保守契約には合いますが、契約期間が不揃いな場合は、日付までの待機アクションと組み合わせる設計も検討することになります。最初は代表的な1パターンで試すのがおすすめです。

ワークフローの基本設定はHubSpotワークフローの設定方法で整理しています。

発注者・情報システム部門・決裁者を関連付けで区別する

IT受託の商談では、窓口が1人ではありません。要件を出す事業部門の担当者、システムの運用を担う情報システム部門、予算を握る決裁者。それぞれの関心事は違います。

関連付けラベルで役割を持たせる

HubSpotでは、取引とコンタクトの関連付けにラベルを付けられます。「決裁者」「要件窓口」「情報システム担当」のように役割をラベルにしておくと、同じ会社の複数の担当者のうち、誰がどの役割かが一覧で分かります。関連付けラベルはProfessionalまたはEnterpriseの契約で使え、セグメントでラベルを条件にする場合も同じくProfessional以上が必要です（出典: HubSpotナレッジベース「create and use association labels」）。

担当の異動で関係が途切れない

IT企業の顧客は、数年のうちに担当者が入れ替わります。コンタクトの記録に、以前のやり取り、参加した会議、送ったメールが残っていれば、後任の営業担当者も、顧客側の新しい窓口も、過去の経緯を前提に話を始められます。ラベルを付け替えるだけで、窓口の交代が反映できるのも利点です。

運用保守の問い合わせと更新営業をつなぐ

保守契約の期間中は、顧客からの問い合わせが発生します。この対応履歴を、更新の営業に活かせるかどうかで、更新の質が変わります。

問い合わせ履歴を更新前の材料にする

問い合わせをチケットとして受け付け、会社レコードに紐づけて残せます。更新の3ヶ月前に、その顧客の問い合わせ件数と内容を見直せば、「障害が多く不満が溜まっていないか」「追加の機能要望が出ていないか」を把握したうえで更新の話を始められます。

Service Hubを使わない場合でも、問い合わせのメールをHubSpotに記録し、メモを残すだけで、更新前の確認材料にはなります。

増額・追加開発の種を拾う

更新時の会話は、追加開発の相談にもつながります。更新取引の中で「追加開発の可能性あり」とチェックを付ける運用にしておけば、新規開発のパイプラインへ橋渡しできます。顧客が自分から言い出す前に、こちらから棚卸しの機会をつくれる点が、保守契約を持つ強みです。

SaaS型の継続課金と異なり、受託・保守は「契約単位で更新判断が入る」点が違います。継続収益の管理を中心にしたい場合はSaaS企業のMRR管理とCRM活用も参考になります。

導入を始める手順

最初から全部を作ろうとすると、運用が重くなります。次の順で、小さく始めるのがおすすめです。

1. 既存の顧客と保守契約の一覧を会社レコードに取り込む ── 契約終了日と更新担当だけを必須にします
2. 新規開発のパイプラインを作る ── 現在の営業の呼び方に合わせて、ステージは5〜7個に抑えます
3. 保守更新のパイプラインと通知のワークフローを作る ── 終了日の前に担当者へタスクが出るかを、数件で試します
4. 決裁者・窓口のラベルを付ける ── 主要顧客から順に埋めていきます
5. 月次で更新予定の一覧を確認する会議を置く ── ツールを入れても、見る場がなければ使われません

導入の支援は、運用を回す体制を整えるための投資だと考えています。自社の営業プロセスに合わせた設計を最初に固めておくと、後からの作り直しが減ります。

よくある質問

Q1. 開発の進捗もHubSpotで管理できませんか

おすすめしません。取引のステージで「開発中」と置くことはできますが、タスクや課題を細かく管理する用途には向きません。進捗の詳細は開発チームのツールに任せ、HubSpotにはフェーズと納品予定日だけを持たせると、二重入力も避けられます。

Q2. 従業員が少ないIT企業でもHubSpotは必要ですか

商談が同時に数件で、担当者が1〜2人ならExcelでも回ります。分かれ目は、保守契約の件数が増えて更新時期の管理が追いつかなくなることと、担当者が増えて「他人の顧客情報を引き継ぐ」場面が出ることです。そのタイミングで入れるのが現実的かなと思います。

Q3. 保守契約の更新通知は、どのプランから使えますか

日付プロパティーを基準にしたスケジュール型のワークフローは、Professional以上のSales Hub・Marketing Hub・Service Hubなどで使えます（出典: HubSpotナレッジベース）。条件は変わることがあるため、導入前に公式ページで確認してください。

Q4. 契約書の管理もHubSpotでできますか

契約の金額・期間・終了日といった「情報」の管理はできますが、契約書の原本の保管や電子署名の運用は、別の仕組みのほうが安全です。HubSpotには契約書ファイルへのリンクだけを残す形が現実的です。

Q5. 業界別のほかの設計も見たいです

業界別の活用方法は業界別HubSpot活用ガイドにまとめています。

まとめ

IT受託・SIの営業管理は、HubSpotで次のように整理できます。

• 引合から保守更新までを、顧客ごとに1本の流れで記録できます。 担当者が変わっても経緯が残ります
• 取引は「新規開発」と「保守更新」の2本に分けます。 見るべき数字が違うためです
• 更新は終了日のプロパティーとワークフローで仕組みにします。 通知の前提条件はプランや日付の持ち方で確認します
• 開発の進捗・課題管理はHubSpotに入れません。 専用のプロジェクト管理ツールに任せます
• 窓口の役割は関連付けラベルで区別します。 異動があっても付け替えるだけで済みます

最初の一歩としておすすめしたいのは、今ある保守契約を一覧にして、終了日が近い順に並べることです。ツールの設定より先に、更新の全体像を見える形にすると、どこから仕組み化すべきかがはっきりします。

自社の営業プロセスにどう当てはめるかを具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現状の運用をうかがったうえで、設計の方向性をご提案します。