HubSpot でプロポーザルと契約書のすべてのバージョンを漏れなく管理する方法

チームが契約書を送りました。しかし、顧客が実際に署名したのはどのバージョンでしょうか？その質問に20分と3つのSlackスレッドを費やす必要はないはずです。しかし、HubSpotを使用している多くの営業チームでは、そうなってしまっています。

案件は「Closed Won」と表示されています。法務部門は正しいPDFを見つけられず、財務部門はどのバージョンが金額と一致するかわかりません。送信した担当者はすでに次の案件に移っているため、署名済みのコピーがどこにあるか誰も把握していません。

解決策は、より厳格な管理や別のスプレッドシートを用意することではありません。ドキュメントに適切な保管場所をHubSpot内に設け、ステータス、バージョン、および関連する案件への明確なリンクを付与することです。

ここでは、チームが何を、いつ、誰に送ったかを常に把握できるよう、proposals、contracts、quotesをHubSpot内で管理する方法をご紹介します。最初の電話から署名まですべてを結びつける方法をより広く把握したい場合は、this walkthroughが参考になります。

案件レコードだけでは不十分な理由

HubSpotの案件はパイプラインと収益管理のために作られており、その点では非常に優れています。しかし、ファイルキャビネットではありません。

チームがすべてを案件に保存しようとすると、すぐに混乱が生じます。前四半期の混乱の中で誰かが作成した15個のカスタムプロパティが残り、長いテキストフィールドにURLが貼り付けられ、営業と法務で意味が異なるステータスラベルが存在するようになります。

1つの案件から、ディスカバリーの要約、提案書、修正済み契約書、最終PDF、更新用ドラフトが生まれることがあります。これらすべてが1セットのフィールドに保存されると、誰かが保存をクリックするたびに履歴が失われてしまいます。

案件にドキュメント情報を一切入れてはいけないということではありません。現在のステージ、見込み金額、最新ファイルへのリンクなどはそこに置くべきです。しかし、ドラフトからレビュー、署名へと移行する契約書のように、独自のライフサイクルを持つものには独自のレコードが必要です。そうすることで、workflowsが安定した基盤を持てます。

カスタムオブジェクトが必要な場合と不要な場合

HubSpotのカスタムオブジェクトを使用すると、コンタクト、企業、案件、チケット以外の独自のレコードタイプを作成できます。1つの案件に複数のファイルを送付し、それぞれを個別に管理する必要がある場合は、「Document」または「Agreement」オブジェクトが適しています。

ただし、常に必要というわけではありません。

チームが案件ごとに1つの提案書と1つの契約書を送付し、バージョン管理が不要であれば、厳格なドロップダウン選択肢を持つ適切な名前の案件プロパティをいくつか用意するだけで十分です。小規模な運用では、それが十分な出発点になります。

並行するドラフト、複数の進行中テンプレート、またはアカウントに送付したすべてのものの明確なリストを管理する必要が生じた時点で、カスタムオブジェクトが大幅に作業を楽にします。案件、企業、および主要なコンタクトにリンクすることで、全員が全体像を把握できます。

オブジェクトの名前は、チームが実際に使う言葉にしてください。「Sales Document」や「Agreement」は、誰も理解できない技術的なラベルよりも適切です。

自動化を組み込む場合は、Portant connects to HubSpotの説明を読んでおくと、オブジェクトの設定がアプリの読み書き対象と一致するようになります。

状況を把握できるプロパティの設定

ステータスは、誰もが異なる内容を入力するフリーテキストフィールドではなく、明確な選択肢を持つドロップダウンにすべきです。例えば、Draft（ドラフト）、In Review（レビュー中）、Ready to Send（送付準備完了）、Sent（送付済み）、Viewed（閲覧済み）、Out for Signature（署名待ち）、Signed（署名済み）、Archived（アーカイブ済み）のような形です。

実際のリストはこれと異なるかもしれません。それで構いません。重要なのは、選択肢が少なく、各ステータスの意味についてチーム全員が合意しており、ワークフローがそれに基づいて動作できることです。

ステータス以外にも、作成日、送付日、署名日、担当者、テンプレート名、ファイルへのリンクといった構造化されたフィールドを追加してください。日付はチェックボックスよりもレポートに役立ちます。各ステップにかかる時間を計測できるためです。

特にcontractsについては、商業的なステータスは案件に、ドキュメントのステータスはドキュメントレコードに保持してください。案件が「Negotiation（交渉中）」を示している一方で、契約書が「In Legal Review（法務レビュー中）」を示すことがあります。この2つが意図的に一致しない場合、リーダーシップチームは推測することなく、どこで進行が止まっているかを把握できます。

履歴を上書きせずにバージョンを管理する

ここで、シンプルな設定が破綻しがちになります。

チームは同じ Google Doc を編集したり、案件上のPDFを置き換えたりすることを「バージョン管理」と言いますが、それはバージョン管理ではなく上書きです。そうすると、メールを掘り返さない限り「3月3日に何を送ったか」に誰も答えられなくなります。

ビジネスで履歴管理が重要な場合（法務や財務が関与する場合はほとんどそうです）、各バージョンを独自のレコードとして扱ってください。バージョン番号、前バージョンへのリンク、タイムスタンプ、変更内容のメモを付与します。

担当者は現在のバージョンだけを気にすれば十分です。「この案件とテンプレートタイプにおいて最も高いバージョン番号がアクティブなもの」というシンプルなルールを設けることで、誰の作業も遅らせることなく整理された状態を維持できます。

ファイルをGoogle DriveやSharePointに保存する場合でも、HubSpotには適切なファイルを1分以内に指し示し、「何を送ったか」に答えられる十分な情報が含まれている必要があります。それが目指すべき水準です。

チームが実際に確認するレポート

ドキュメントレコードが存在すれば、リーダーシップが本当に役立つと感じるレポートを構築できます。

まず小規模なセットから始めてください。数日以上レビュー中で止まっているドキュメント、提案書が送付されていない後期ステージの案件、適切な企業にリンクされていない署名済み契約書を持つアカウント、そして今四半期のセグメント別署名済みドキュメント数などです。

カスタムオブジェクトはこの用途に最適です。案件ボードを煩雑にすることなく、ドキュメントフィールドでフィルタリングやグループ化ができます。パイプラインの指標は案件に、ドキュメントの指標はドキュメントオブジェクトに残り、両方が1つのダッシュボードに表示されます。

ドキュメントと案件の間のリンク漏れは個人の失敗ではありません。自然に発生するデータのギャップです。「ドキュメントレコードが不足している案件」の週次リストは、四半期末の混乱ではなく、5分間の簡単な整理作業で済みます。

ドキュメントを適切な案件に紐付ける

ドキュメントを案件にリンクすることは、形式的な手続きではありません。どの会話がどのファイルにつながったかを証明する方法です。

デフォルトの設定は通常、多数のドキュメントを1つの案件に紐付け、アカウントレベルの表示のために企業へのオプションリンクを追加する形です。ほとんどのチームにとってこれで十分です。

更新が新しい案件を生成する場合、古いドキュメント履歴を企業レコードを通じて引き継ぐか、手動で再リンクするかを事前に決定してください。そうすることで、CSチームが毎回の更新ミーティングをゼロから始める必要がなくなります。

案件の金額とライン項目は収益の正確な情報源として維持します。ドキュメントレコードには、交渉中に変わることがある、提示および合意された内容が記録されます。両方が見えるべきです。予測用の案件フィールドと、実際に送付された内容のドキュメントフィールドです。案件を「Closed Won」としてマークする前に2つを比較するワークフローのステップを追加することで、不一致を早期に検出できます。

この管理を徹底しているチームは、四半期末のレビューを迅速に行え、「待って、何に署名したんだっけ？」という事態が減ります。

優れた自動化の姿

自動化は、データモデルを回避するのではなく、データモデルと連携して機能すべきです。

PortantがHubSpotからファイルを生成する際、CRM内の何かが同時に更新される必要があります。新しいドキュメントレコード、ステータス変更、タイムスタンプ、またはタイムライン上のアクティビティなどです。メール内にのみ存在し、CRMレコードが存在しないPDFは、スプレッドシート管理に逆戻りします。

案件ステージの変更をトリガーにするか、レコード上のボタンをトリガーにするかにかかわらず、機能するパターンは次の通りです。まずドキュメントレコードを作成または更新し、ファイルを生成し、実際に起きたことに基づいてステータスを変更します。生成に失敗した場合は、ステータスにその旨が表示され、担当者にタスクが割り当てられる必要があります。

Portantはこれをすぐに対応できます。HubSpot認定アプリであり、ライブCRMデータからドキュメントを生成し、案件レコード上でアクティビティを可視化します。チームはメールやDriveを確認することなく、何が送付されたかを把握できます。

よくある質問

HubSpot のカスタムオブジェクトを使ってドキュメントを管理すべきでしょうか？

それは送信量によります。1件の取引に対して複数のドキュメントを送信し、適切なバージョン管理とレポートが必要な場合は、カスタムオブジェクトがデータを整理する最適な場所となります。1件の提案書と1件の契約書のみで、バージョン履歴も不要であれば、適切に構成された取引プロパティで対応できます。

HubSpot でドキュメントのバージョン管理はどのように設定すればよいですか？

各バージョンを独立したレコードとして扱い、バージョン番号、前バージョンへのリンク、タイムスタンプ、作成者の情報を記録してください。法務や財務が草稿間の変更内容を確認できるよう、単一フィールドを上書きするのは避けましょう。

HubSpot でドキュメントレコードを取引に紐付けるにはどうすればよいですか？

ドキュメントオブジェクトから取引へのアソシエーションを作成し、必要に応じて企業や連絡先にも紐付けます。多くのチームは多対1の設定、つまり複数のドキュメントを1件の取引に紐付ける形を採用しています。HubSpot が対応している箇所では必須アソシエーションを設定し、孤立レコードを早期に検出できるようにしましょう。

HubSpot でドキュメントのステータスを管理するのに最適なプロパティはどれですか？

ライフサイクルステータス用の管理されたドロップダウン（Draft、In Review、Sent、Signed など）に加え、レポート対象の各マイルストーンに対して個別の日付フィールドと担当者フィールドを設定します。これにより、ワークフロー、リスト、ダッシュボードを安定して運用できます。

Portant は HubSpot でのドキュメント管理に活用できますか？

はい。Portant は HubSpot 認定アプリであり、CRM のライブデータからドキュメントを生成し、アクティビティを取引レコード上で可視化します。ドキュメントのステータスをワークフローと連携させることで、チーム全員がミーティングやレポートで同じ情報を確認できます。