契約書に誤った当事者名が記載されることは、単に恥ずかしいだけでは済みません。合意そのものが無効になる可能性があります。以前のバージョンからコピーされた古い法人名を法務部門が発見し、商談が何週間も停滞するのを目の当たりにしてきました。買い手側のCFOが他の優先事項へと移ってしまう中、担当者が反対署名を待ち続けて勢いを失っていくのも見てきました。そして、MSA、注文書、修正契約書にまたがるバージョン管理が、何かが壊れるまで誰も責任を持たない業務上のリスクへと変わっていく場面も経験してきました。
契約書は、営業スピードと法的責任が交差する重要なドキュメントです。そのため、自動化が最も難しい書類でありながら、うまく実現できれば最大の成果をもたらします。このプレイブックでは、Portantを使用してHubSpotで契約ワークフローを構築する方法を解説します。テンプレートの設計、CRMデータのマージ、社内レビュー、電子署名、コンプライアンス、署名後のストレージまでを網羅しています。MSA、SOW、NDA、注文書を処理するHubSpotの営業チームで広く採用されているアーキテクチャと同じ構成です。
テキストが不完全なようです。翻訳するテキストを完全な形でご提供ください。 HubSpot向け契約自動化。パイプラインのコンテキストとして、 発見から署名済み契約まで、一つの流れで このガイドと組み合わせると効果的です。また、商談サイクルの初期段階にある場合は、まずは HubSpot での提案書作成を自動化 または HubSpot での見積もりを自動化する.
ブログのその他の記事： HubSpot での契約更新の自動化, HubSpot ワークフローにおける電子署名、および Google Docs の契約書における電子署名フィールド.
HubSpot チームにとって契約自動化が重要な理由
ほとんどの HubSpot チームが抱えているのは、一つの契約上の問題ではありません。五つの契約上の問題が積み重なっているのです。
まず、データの正確性という問題があります。担当者が HubSpot のレコードから Google Doc に会社名をコピーする際、法人名ではなく商号を取得してしまうことがあります。あるいは、住所を記憶で入力してしまうこともあります。または、前回の取引のハードコードされた数字がテンプレートに残っているため、前四半期の価格をそのまま貼り付けてしまうこともあります。手作業でのデータ転記が行われるたびに、当事者が合意していない内容が契約書に記載されてしまうリスクが生じます。
2つ目は、レビュー時の摩擦です。契約書には法務レビューが必要です。しかし、法務チームは HubSpot を使いません。また、新しいツールを覚えたいとも思っていません。そのため、契約書は添付ファイルとしてメールで送られ、修正は別のスレッドで行われ、戻ってくる頃には担当者はどのバージョンが最新なのかを見失っています。ディールステージには「契約送付済み」と表示されていても、送付したバージョンが承認済みのものかどうか誰にもわからないため、パイプラインレポートの信頼性が失われます。
3つ目は署名のロジスティクスです。契約書に署名してもらうには、適切な文書を適切な担当者へ届け、適切な署名体験を提供する必要があります。副署名が加わると、さらに複雑な層が生じます。法務チームが購買者の署名を確認してからCEOが副署名を行うといった場合、署名の順序も重要になります。ステップが増えるたびに、プロセスが停滞するリスクが生まれます。
4つ目は、保存と検索です。契約が締結されてから6ヶ月後、誰かが署名済みのMSAを探す必要が生じます。そのPDFが担当者の個人的なDriveフォルダに「Contract_Final_v3_SIGNED(2).pdf」のようなファイル名で保存されていたとしたら、見つけ出すのは至難の業です。契約書には、一貫した命名規則、一貫した保存場所、そしてCRMレコードへのリンクが不可欠です。
5つ目はコンプライアンスです。電子署名はほとんどの法域で法的に有効ですが、「ほとんど」という言葉には大きな意味が含まれています。法務チームは、どの法律が適用されるか、監査証跡に何が記録されるか、そして署名プロセスが業界の規制要件を満たしているかどうかを把握する必要があります。
契約の自動化は、ライフサイクル全体をCRM内で完結させることで、これらの課題を解決します。テンプレートがライブデータを取得するため、名前や条件は常に最新の状態に保たれます。レビューは案件が存在する場所で行われます。別のサイロを追加することなく、署名が収集されます。そして署名済みのコピーは、予測可能な場所に予測可能な名前で保存されます。これが、本プレイブックが構築するアーキテクチャです。
HubSpot における契約ライフサイクル
セットアップの手順に入る前に、全体的なライフサイクルを把握しておくと役立ちます。HubSpot における契約ワークフローは、6つのステージを経ます。
- テンプレートの作成。 Google Docs（テキスト中心の契約書向け）またはGoogle Slides（ビジュアルSOW向け）で契約テンプレートを作成し、CRMプロパティ用の差し込みタグを追加します。
- CRMデータの差し込み。 担当者がDeal、Company、Contact、またはTicketからワークフローを起動すると、Portantはテンプレートにリアルタイムのプロパティ値を取り込みます。出力されるのは、案件固有の完成したドキュメントです。
- 内部レビューと承認。 法務、財務、またはリーダーシップチームが、バイヤーに送付する前に結合されたドキュメントをレビューします。誰かが承認するまで、ドキュメントは HubSpot レコード上で下書きステータスのままになります。
- 電子署名の収集。 承認後、Portantはドキュメントを署名のために送信します。署名者は取引の関連付けからマッピングされます。副署は順番に続けることができます。
- 署名済みコピーの保存。 署名済みのPDFは、一貫した命名規則でGoogle Driveに保存されます。HubSpotのレコードにはリンクが表示されます。
- ステータスの追跡と更新。 Portantのディールレコードにカスタムプロパティを設定することで、契約ステータスのレポート作成、更新リマインダーのトリガー、そしてリーガルオペレーション向けダッシュボードの構築が可能になります。
このライフサイクルを（5つのツールに分散させるのではなく）HubSpot内で完結させることには、3つの理由があります。監査証跡が一元化されるため、コンプライアンス管理がシンプルになります。取引ステージが実際のドキュメント状況を反映するため、レポートの信頼性が高まります。そして、担当者が契約書の作成・確認・送付のためにCRMを離れる必要がなくなるため、担当者の業務体験が向上します。
取引に関するすべての書類を一か所にまとめるための包括的なアーキテクチャについては、こちらをご覧ください HubSpot におけるドキュメント自動化の完全ガイド.
契約書のテンプレートデザイン
契約書は、提案書や見積書とは構造的に異なります。提案書は説得を目的とし、見積書は商業的な性格を持ち、契約書は法的拘束力を持ちます。この違いが、テンプレートの設計方法に影響を与えます。
法的文書の言語は、データの差し込み後も正確さを保つ必要があります。「Company」や「Client」などの定義済み用語は、文書全体を通じて一貫して使用する必要があります。テンプレートで「Company」を最初の段落に登場する法人として定義する場合、その法人の差し込みタグは該当の定義箇所に正確に配置する必要があり、その後のすべての参照箇所では、差し込み値を再度使用するのではなく、定義済み用語をそのまま使用する必要があります。
署名欄には適切な構造が必要です。契約書の署名欄には通常、法人名、署名者の氏名（活字体）、役職、および日付欄が含まれます。これらはそれぞれ差し込みタグとして設定できますが、レイアウトも重要です。Portantの電子署名機能はドキュメント上に署名フィールドを重ねて表示するため、テンプレートにはそれらのフィールド用の十分なスペースを確保しておく必要があります。
MSAでは、別紙の参照が一般的です。基本契約書では、料金については「別紙A」、作業範囲書については「別紙B」を参照します。これらの別紙が別々のワークフローにおける独立した文書である場合、テンプレートには名称で参照を記載する必要があります。同一文書内に含まれる場合は、改ページと明確な見出しを設けることで、読みやすさを保つことができます。
Google Docsは、MSA、NDA、サービス契約など、法律的な文章が中心となる契約書に適しています。一方、図表やタイムライン、ブランドデザインのレイアウトを条件と組み合わせて掲載したいビジュアル重視のSOWには、Google Slidesの方が適しています。
マージタグの設定方法については、こちらをご覧ください テンプレートのカスタマイズ．タグの構文と数式については、 タグの数式 条件付きロジックと書式設定について説明します。
HubSpotから契約書を生成する
テンプレートワークフローを、契約を管理する HubSpot オブジェクトに連携させましょう。契約書の場合、通常は Deal（商取引の当事者）に、Company（法人情報）と Contact（署名者）が紐付いた構成になります。Deal には商業条件（価格、契約期間、発効日）が含まれます。Company には法的詳細（登録名、住所、管轄）が含まれます。Contact には署名者情報（氏名、役職、メールアドレス）が含まれます。
この3つのオブジェクトのパターンが重要なのは、契約書が3つすべてを参照するからです。提案書はディールと連絡先だけで済む場合があります。見積書はディールと明細項目だけで済む場合があります。しかし契約書には、会社からの法人情報、ディールからの商業条件、そして連絡先からの署名者の詳細が必要です。Portantは、関連するすべてのオブジェクトから一度のマージで情報を取得します。
どのプロパティが最も重要か
契約書生成において、以下の HubSpot プロパティが最も重要な役割を果たします。
- 会社：法人名。 「担当者が気軽に入力する「Company name」フィールドではありません。正式な登録名称のことです。HubSpot に専用の法人名プロパティがない場合は、新たに作成してください。契約書の正確性において、最も重要なフィールドです。
- 会社：請求先住所。 国名を含む完全な住所。契約書には準拠法への言及が含まれており、住所は管轄権の判断基準となることが多いです。
- 取引：金額と通貨。 契約の商業的価値。
- 取引：クローズ日または発効日。 契約が発効するタイミング。一部のチームでは、取引のクローズ日の代わりに、カスタムの「Contract Effective Date」プロパティを使用しています。
- 取引：契約期間。 契約の有効期間です。カスタムプロパティ（例：「Contract Term Months」）を使用することで、これを明示することができます。
- 連絡先：氏名とタイトル。 署名欄用。
- 連絡先：メール。 電子署名リクエストのために。
必須プロパティが空の場合、Portant は空白をマージします。ドキュメントは、値が入るべき箇所に空欄が生じた状態でレンダリングされます。だからこそレビューステップが重要です。契約書が買い手に届く前に、空白のマージを検出できます。データ品質管理のベストプラクティスとして、 HubSpot データを監査して正確なドキュメントを作成 自動化の前に確認すべき事項を解説します。
HubSpot でレコードを開き、Portant パネルを使用してワークフローを開始してください。モーダルが表示されたら関連する連絡先を選択し、適切な署名者と請求担当者がタグに正しく反映されるようにしてください。
段階的なリファレンス： HubSpot でドキュメントを作成するカスタムプロパティに Portant が書き戻すことで、後続の HubSpot ワークフローをトリガーできます。詳細はこちらをご覧ください HubSpot のワークフローを Portant からトリガーする.
契約書のレビューと承認
契約書は、提案書や見積書よりも厳格な確認が必要です。提案書に誤字があれば気まずい思いをするだけですが、契約書に誤った条項があれば法的責任が生じます。見積書に古い価格が記載されていれば利益が損なわれますが、契約書に古い価格が記載されていれば、誤った数字で拘束力のある義務が発生します。
だからこそ、契約ワークフローにおけるレビューステップは省略できないのです。それは「ドキュメント生成済み」と「署名のためにドキュメント送付済み」の間にある重要な関門です。
契約書にマルチ承認フローが必要な理由
ほとんどの営業書類には承認者が1人必要です。契約書には2人または3人必要なことが多いです。
- 法的事項 レビュー言語、定義された用語、責任条項、およびコンプライアンス要件。
- ファイナンス 商業条件（価格設定、支払条件、収益認識への影響）を審査します。
- セールスリーダーシップ 標準外の条件（閾値を超える割引、カスタムSLA、支払い期間の延長）を審査します。
Portantのレビューブロックは、2つのモードで複数の承認者をサポートしています。「全員必須」モードでは、ワークフローを続行する前に、割り当てられたすべての承認者が承認する必要があります。「いずれか1人」モードでは、1人が承認するだけで文書がリリースされます。契約書の場合、「全員必須」がほぼ常に適切な選択です。財務部門が商業条件を確認していない状態で、法務部門だけが文言を承認するような事態は避けるべきです。
下書きステータスの仕組み
レビューブロックが有効な間、ドキュメントはドラフトステータスのままになります。このステータスは、Portantのカスタムプロパティを通じてHubSpotレコード上で確認できます。これはパイプラインレポートにとって重要な意味を持ちます。取引ステージが「Contract Sent」になっていても、ドキュメントがまだドラフトの状態であれば、パイプラインの進捗が実態より過大に表示されてしまいます。ドラフトステータスを使用することで、マネージャーやRevOpsの担当者が別のツールを確認しなくても、この状況を把握できるようになります。
レビューが承認されるまで、後続のワークフローブロック（電子署名リクエストなど）は保留されます。権限を持つ担当者が準備完了と承認するまで、契約書は買い手に送付されません。これは、法的書類において求められる動作です。
詳細なレビュー設定については、こちらをご参照ください ドキュメントのレビューと承認。収益業務における承認デザインパターンについて、 HubSpot ドキュメント承認ワークフローガイド 複数ステップの承認アーキテクチャについて説明します。
HubSpot内で承認
法務チームは新しいツールを覚えたいとは思っていません。すでに使い慣れた場所でドキュメントを確認し、承認したいのです。承認者が HubSpot を使用しているなら、ネイティブのレビューフローでまさにそれが実現できます。
Portantカードはディールレコード上にドキュメントの現在のステータスを表示します。ドキュメントが承認待ちの状態になると、承認者はレコードから直接モーダルを開き、契約書を確認して承認または却下を行います。コンテキストの切り替えは不要です。「別のプラットフォームへのリンクをメールでご確認ください」といった手間もありません。
これは、弁護士が日常的に HubSpot を使用しているわけではないものの、依頼があった際に特定の取引レコードを確認する企業の法務チームにとって特に重要です。担当者は取引を開き、モーダル内で契約書を確認し、画面を離れることなく承認できます。取引レコードが契約ステータスの唯一の信頼できる情報源として機能します。
完全なウォークスルー： HubSpot でドキュメントをレビューおよび承認する.
契約書の電子署名
契約書への署名は、他の署名ユースケースとは異なります。提案書では購入者からの署名が1つあれば十分な場合もありますが、契約書では多くの場合、特定の順序で複数の署名が必要となり、それぞれに法的主体に関する要件が付随します。
署名者をディール関連付けからマッピングする
署名者のメールアドレスは、商談に関連付けられたコンタクトから取得されます。一般的な契約フローでは、商談の主要コンタクトが買い手側の署名者となります。しかし、契約書には多くの場合、自社チームからの副署名が必要となります。CEO、営業副社長、または署名権限を持つ担当者からの副署名が求められます。
Portantは順次署名をサポートしています。まず買い手が署名し、その後、副署名者がドキュメントを受け取ります。または、内部プロセスにおいて買い手が最終版を確認する前に自社の署名が必要な場合は、順序を逆にすることもできます。署名の順序は、ツールの仕様ではなく、法務チームの実行プロセスに合わせて設定できます。
署名体験の流れ
署名者がリクエストを受け取ると、ドキュメントへのリンクが記載されたメールが届きます。署名者は署名前に契約書の全内容を確認できます。署名インターフェースには、署名、イニシャル、日付を入力する箇所が明確に表示されます。署名完了後、署名者には署名済みドキュメントのコピーが添付された確認メールが送信されます。
買い手側にとって、このプロセスは非常にシンプルです。アカウントを作成する必要はありません。ソフトウェアをダウンロードする必要もありません。リンクをクリックし、内容を確認して署名するだけで、確認通知が届きます。「契約書を受け取る」から「契約書に署名する」までのステップが少ないほど、商談の成立は早くなります。
順次署名、複数署名者の設定、および確認メールのカスタマイズについては、こちらをご覧ください 電子署名リクエスト。複数の署名者に特化した点として、 複数の署名をリクエスト セットアップについて説明します。より広範な 電子署名の概要 署名機能のすべてのリンクを含む プレビューリンク, 再送信、および 監査証跡.
コンプライアンス：法務チームが知っておくべきこと
私は法律の専門家ではありませんし、ブログ記事も同様です。ただし、法務チームに適切な参考資料をご案内し、プラットフォームが何を記録するかについてご説明することは可能です。
電子署名は、ほとんどの主要な法域において法的に有効です。米国にはESIGNおよびUETAがあります。EUにはeIDASがあります。英国、カナダ、オーストラリア、ニュージーランドにも、それぞれ独自の法的枠組みがあります。簡単にまとめると、標準的な商業契約（B2B SaaS契約、サービス契約、NDA）については、電子署名は一般的に法的拘束力を持ちます。特定の法域における特定の文書種別には例外が存在するため、法務チームが関連する法的枠組みを確認することが重要です。
この文章は途中で終わっているようです。翻訳する英語テキストの全文を送信してください。 eSigning に関する法律とコンプライアンスオーストラリア、カナダ、EU、イスラエル、ニュージーランド、英国、米国をカバーしています。法律顧問が電子署名の有効性について問い合わせた際は、そちらをご案内ください。ポリシーチームは、これらの参考情報を自社のリスク評価に照らし合わせて整理することができます。
監査証跡
監査証跡には、誰がいつ署名したか、その際のIPアドレス、および署名時点のドキュメントハッシュが記録されます。これにより、文書が実行後に改ざんされていないことを証明する法的証拠記録が作成されます。規制対象業界（医療、金融サービス、政府調達）において、監査証跡はあれば便利という機能ではなく、コンプライアンス上の要件であることが多いです。
Portantの監査証跡は、署名済みドキュメントに添付されます。法務チームは、あらゆる契約書の署名順序、タイムスタンプ、および署名者の本人確認を検証できます。詳細を見る 電子署名に監査機能を追加 設定の詳細については、こちらをご覧ください。
規制対象業界向け： 契約書に特定の認証レベル（eIDAS に基づく適格電子署名など）が必要な場合は、本番運用前に法務チームとともにコンプライアンス上の参照事項を確認してください。標準的な電子署名は商業契約の大多数をカバーしていますが、業界によっては追加要件が設けられている場合があります。
契約の種類と使い分け
すべての契約が同じというわけではなく、自動化のパターンは契約の種類によって異なります。以下は、HubSpot チームがよく自動化する一般的なパターンです。
マスター・サービス・アグリーメント（MSA）
MSAは、継続的な関係の基盤となる契約書です。責任、補償、準拠法、知的財産の所有権、機密保持といった一般条項が含まれています。商業上の詳細（価格、範囲、スケジュール）は、MSAを参照する別個の注文書またはSOWに記載されます。
MSAは取引固有のフィールドが少ないため、テンプレートの大部分は、当事者名、住所、発効日、および準拠法のマージタグを含む静的な法的文書となっています。MSAはその後のすべての法的枠組みを定めるものであるため、レビューのステップは非常に重要です。参照 SaaS契約管理 MSAが広範な契約体系にどのように組み込まれるかについて。
作業範囲記述書（SOW）
SOWはMSAの下で特定の案件におけるスコープと価格を定義します。成果物、スケジュール、リソース配分、マイルストーン、支払いスケジュールなど、案件ごとに内容が変わります。SOWテンプレートは差し込みタグの使用頻度が高く、定型的な法律文言は少なめになる傾向があります。
Google Slidesは、プロジェクトのタイムラインやアーキテクチャ図などのビジュアル要素を条件と併せて掲載する必要があるSOWに適しています。Google Docsは、詳細なプロジェクト計画に近いテキスト中心のSOWに適しています。
秘密保持契約（NDA）
NDAはシンプルで件数が多く、パイプラインの早い段階でよく発生します。担当者は見込み客を選定し、製品の詳細や価格を共有する前に相互NDAの締結が必要になります。テンプレートは短く（2〜4ページ）、標準的な相互NDAではレビューが省略されることも多く、署名のフローも簡単です。
NDAは件数が多く内容のばらつきが少ないため、完全自動化に適した候補です。取引ステージの変更をトリガーとして、手動レビューなしで生成し、署名のために送信することができます。NDAのパターンの詳細については、こちらをご覧ください 契約の構成要素.
注文フォーム
注文書は既存のMSAと組み合わせて使用します。内容は主に商業条件、つまり製品、数量、価格、支払いスケジュール、契約期間で構成されます。注文書はMSAを日付で参照し、案件固有の数値を追加します。テンプレートは明細項目の差し込みタグが多く、法的文言は少なめです。
HubSpot の取引から明細項目が直接、注文書テンプレートに反映されます。明細項目の設定については、こちらをご覧ください Portant の明細項目.
修正事項
修正条項は既存の契約を変更するものです。元の契約を日付と当事者によって参照し、変更内容を明記します。一般的な修正条項の例として、価格調整、期間延長、範囲の変更、追加製品などが挙げられます。
修正契約書のテンプレートには、現在の取引と元の契約書の両方から情報が必要です。元の契約日と参照番号をカスタムプロパティとして取引に保存しておけば、修正契約書のテンプレートが自動的にそれらを取得できます。
取引ステージからの契約書自動生成
Portantカードからの手動生成は、少量のチームには適しています。しかし、月に50件以上の契約を処理するチームでは、商談ステージの変更から自動的に生成がトリガーされることが求められます。
よくあるパターンとして、案件が「Contract」ステージ（またはパイプラインで設定しているステージ名）に移動すると、HubSpot のワークフローが案件を登録し、Portant をトリガーして契約書を生成します。契約書が作成されてレビューステップで保留され、担当承認者に通知が送られます。
タイミングが重要です
契約は通常、提案の承認後に作成されます。購入者が提案に同意すると、担当者が商談ステージを更新し、契約書が生成されます。このタイミングを適切に管理することで、契約書が早まって生成されること（購入者が条件に同意する前）や、遅れて生成されること（購入者が契約書の受領を期待した後）を防ぐことができます。
チームによっては、2段階のトリガーを使用するところもあります。案件が「口頭合意」に移動すると、契約書がドラフト状態で生成されます。その後、法務部門が承認し、署名依頼が送信されて初めて、案件が「契約送付済み」に移動します。これにより、パイプラインのステージが正確に保たれ、「契約送付済み」ステージにレビューされていない書類が含まれるのを防ぐことができます。
生成後に保持するパターン
最も信頼性の高い契約自動化のパターンは、まず生成し、その後法務が承認するまでレビュー段階で保留するというものです。つまり、ワークフローが自動的にドキュメントを作成し（担当者による手動生成の手間を省きます）、自動送信は行わない（法務レビューのゲートを維持します）という仕組みです。
担当者の仕事はシンプルになります。取引ステージを更新し、プレビューが正しいか確認し、契約書のレビュー準備ができた旨を法務部門に通知するだけです。法務部門の仕事はこれまでと変わりません。契約文言のレビュー、条件の確認、承認または却下です。その人間によるチェックポイントの間にあるすべての作業は、自動化が処理します。
ワークフロー自動化の設定については、こちらをご覧ください 自動化機能HubSpot のワークフロートリガーについては、 HubSpot のワークフローを Portant からトリガーする 統合をカバーしています。
署名後の管理：保存、追跡、更新
契約書に署名をもらうことは、業務の半分に過ぎません。署名後に何が起こるかによって、法務オペレーションが本当にスケールするかどうかが決まります。
署名済みコピーの保存先
Portantは、設定した出力フォルダと命名規則を使用して、署名済みPDFをGoogle Driveに保存します。署名済みドキュメントは、Portantのカスタムプロパティを通じてHubSpotの取引レコードにもリンクされます。つまり、アクセス方法は2通りあります。Driveでファイルを検索するか、取引レコードを開いてリンクをクリックするかです。
OneDrive を使用しているチームにも、Portant は対応しています。詳細はこちら OneDriveに保存 設定のために。
命名規則は重要です
6ヶ月後、誰かが特定の契約書を探す必要が生じるかもしれません。すべてのファイルが「Contract.pdf」という名前であれば、一つひとつドキュメントを開いて確認することになります。会社名・契約種別・日付を含む命名規則を設けることで、ファイルを開かずに目的の契約書を見つけられるようになります。
Portantでは、差し込みタグを使って出力ファイル名を作成できます。「{Company Name} - MSA - {Date}」のようなパターンを設定すると、「Acme Corp - MSA - 2026-03-15.pdf」のようなファイル名が生成されます。これはDriveのフォルダー構造とHubSpotレコードの参照の両方に対応しています。参照してください 出力ファイル名をカスタマイズする セットアップのために。
契約ステータスレポート
Portantは、ドキュメントのステータス、署名のステータス、署名日などのカスタムプロパティをHubSpotのディールに書き戻します。これらのプロパティにより、契約活動に関するHubSpotレポートが可能になります。RevOpsチームは、レビュー待ちの契約、署名待ちの契約、今月署名された契約、生成から署名までの平均時間などを表示するダッシュボードを構築できます。
最後の指標（生成から署名までの時間）は、契約ワークフローの健全性を示す最良の指標の一つです。この数値が増加傾向にある場合、レビューまたは署名プロセスのどこかで遅延が生じています。HubSpot のプロパティを活用することで、カスタムレポートツールを使わずにこの状況を可視化できます。
更新リマインダー
契約に固定期間がある場合、成約日（またはカスタムの「契約終了日」プロパティ）を活用して更新リマインダーを設定できます。終了日の90日前にトリガーされる HubSpot ワークフローを使用することで、タスクの作成、通知の送信、または更新パイプラインへの案件の登録が可能になります。更新契約には、日付と条件を更新した同じテンプレートをそのままご利用いただけます。
これにより、契約ライフサイクルのループが完結します。生成から署名、更新まで、すべてが HubSpot のレコード上で管理されます。
出力管理とストレージオプションについては、こちらをご覧ください 出力ドキュメント。契約書を整理されたDriveフォルダに自動的に保存するには、 出力ファイルの自動保存 セットアップをカバーしています。
契約自動化でよくある間違い
契約ワークフローの設定を十分なチームでサポートしてきた経験から、同じミスが繰り返されるのを目にしてきました。以下の点にご注意ください。
テンプレートにハードコードされた日付と名前。 最もよくあるミスです。テンプレートを作成し、当事者名フィールドに「Acme Corp」と入力したまま、マージタグへの置き換えを忘れてしまうケースがあります。その後に作成された20件の契約書にはすべて「Acme Corp」と記載されることになります。取引固有のデータにはすべてマージタグを使用してください。契約ごとに変わる情報は、マージタグとして設定するのが鉄則です。
「標準」契約のレビューを省略すること。 チームは、ルーティンとみなす契約のレビューをスキップすることがあります。AIが生成した条項が予期しない文言を含んでいたり、マージが古いプロパティ値を引き込んだりするまでは、それで問題ないように見えます。標準的な契約書であっても、最低でも1人の目による確認が必要です。標準的な契約のレビューを迅速化したい場合は、3人ではなく1人の承認者を設定してください。レビューを完全にスキップしてはいけません。
エッジケースでのテストを行っていない。 テンプレートは、案件に連絡先が1件、会社情報が完全、カスタムプロパティがすべて入力されている場合には完璧に機能します。しかし、連絡先が2件ある場合はどうなるでしょうか。会社の住所が空欄の場合は。契約期間のプロパティが未設定の場合は。本番運用前に、不完全なデータでテストしてください。プレビューステップでこうした問題を確認できますが、それは実際に確認する人がいる場合に限ります。
法人名が誤っています。 HubSpot の「Company name」フィールドは、登録された法人名（「Acme Corporation, Inc.」）ではなく、略称（「Acme」）が入力されていることがよくあります。契約書テンプレートが誤ったプロパティを参照している場合、正しい法人に対して契約が執行できない可能性があります。専用の「Legal Entity Name」プロパティを作成し、データ品質を徹底してください。詳しくはこちらをご覧ください クリーンな営業ドキュメントのためのHubSpot プロパティ プロパティデザインパターンのために。
相手方の署名設定なしで送信します。 契約書に自社側の副署が必要な場合は、署名フローにそのステップが含まれていることを確認してください。買い手のみが署名した契約書は、御社の権限ある署名者が署名するまで法的拘束力を持たない場合があります。公開前に、ワークフロー内で副署者を設定してください。
監査証跡の欠落。 法務チームが監査証跡を必要としているにもかかわらず、有効化していない場合、署名済みの文書には必要な法的記録が残りません。監査証跡は、契約書を送付する前に有効化してください。送付後では間に合いません。署名済みの契約書に後から監査証跡を追加することはできません。
ファイル名の不統一。 担当者ごとに異なる命名規則を使用していると、後から契約書を探す作業が一苦労になります。ワークフローテンプレートで命名規則を設定すれば、自動的に適用されます。ファイルの命名を担当者任せにしないようにしましょう。
よくある質問
PDFをソースなしでアップロードして署名することはできますか？
はい。PDFを直接アップロードし、差し込みワークフローを経由せずに署名のために送信することができます。これは、相手方の法務チームが作成した契約書など、テンプレートシステム外で作成された契約書に対して有効です。詳細はこちらをご覧ください PDFアップロードによる手動署名リクエスト ウォークスルーについては、
複数の署名者はどのように機能しますか？
Portantは、順次または並行して複数の署名者をサポートしています。順次署名とは、署名者1がリクエストを受け取って署名した後、署名者2がそれを受け取る方式です。これは、買い手が先に署名し、売り手が後から副署する契約書の標準的なパターンです。署名の順序はワークフロー内で設定します。参照： 複数の署名をリクエストする.
署名済みファイルはどこに保存されますか？
署名済みの出力は、ワークフローで設定した出力フォルダと命名規則に従って Google Drive（または OneDrive）に保存されます。また、Portant のカスタムプロパティを通じて HubSpot の案件レコードにもリンクが表示されます。これにより、署名済み契約書を見つける方法が2つ用意されます。CRM レコードから確認する方法と、ファイルシステムから確認する方法です。命名規則については、法務チームのファイリング要件に合わせて設定してください。
Word テンプレートを Google Docs の代わりに使用できますか？
Portantのマージ機能は、Google DocsおよびGoogle Slidesのテンプレートに対応しています。既存のWordテンプレートをお持ちの場合は、Google Docsにインポートし、差し込みフィールドをPortantタグに変換することができます。テキストが中心の契約書であれば、書式設定は概ねそのまま引き継がれます。出力形式については、PortantはGoogle DocsテンプレートからPDF、Wordファイル（.docx）、その他の形式で生成することができます。詳細はこちらをご覧ください Microsoft Word 出力 詳細については。
契約修正はどのように処理しますか？
元の契約を日付と当事者で参照する独立した修正契約テンプレートを作成します。元の契約日と参照番号をHubSpot dealのカスタムプロパティとして保存し、修正契約がマージタグ経由でそれらを取得できるようにします。修正契約のワークフローは、元の契約と同じ生成・レビュー・署名のパターンに従います。チームによっては、修正契約用に新しいdealを作成して同じ企業に関連付ける場合もあれば、既存のdealのプロパティを更新して使用する場合もあります。
署名者のメールがバウンスした場合はどうなりますか？
署名リクエストのメールが配信できない場合、署名ステータスに失敗が反映されます。HubSpotのレコードで連絡先のメールアドレスを更新し、署名リクエストを再送信できます。参照： 署名リクエストを再送信する 配信エラーの処理方法および更新済みアドレスへの再送信方法について。
契約が広範な取引サイクルの中でどのように位置づけられるかについての詳細は、 契約ライフサイクル管理 戦略的な視点をカバーしています。また、HubSpot のドキュメント自動化の導入初期段階にあるチームには、 PortantのHubSpot連携の仕組み 技術的な基盤について説明します。
