Portant Docs
ホームページ HubSpot にインストール 無料で始める

HubSpot でのドキュメントレコードの管理

Portant は生成したすべてのドキュメントを、Document オブジェクト（Portant アプリが提供する HubSpot アプリオブジェクト）の独自レコードとして HubSpot に書き込みます。各レコードは、ワークフローを実行した元の取引先、コンタクト、会社、チケット、またはカスタムオブジェクトに関連付けられます。

目的はドキュメントをレポートの対象にすることではありません。ドキュメントそのものがビジネスプロセスであるということです。ドキュメントは見積もり、契約書、請求書、提案書、または作業範囲記述書（SOW）です。各ドキュメントがステータスと日付を持つレコードになれば、以前は回答できなかった問いが通常の HubSpot レポートで答えられるようになります。先月署名された契約の件数、担当者ごとに送付した見積もりの件数、3 回も見積もりを送ってまだ署名されていない取引、一度も開封されなかった署名依頼などです。

これまで、取引先やコンタクトの Portant プロパティには最新のドキュメントのみが保存され、実行のたびに上書きされていました。見積もり、修正見積もり、署名済み契約書がある取引でも、表示される値は 1 セットだけでした。ドキュメントレコードはこの 3 つすべてを保持します。

このガイドの内容:

  1. ワークフローにドキュメントの種類を示す名前を付ける
  2. 計測できる指標
  3. 実行する価値のあるオートメーション
  4. ドキュメント側または取引側のオートメーション
  5. 契約の更新と期限切れ
  6. リファレンス: 各レコードの内容
  7. レコードの作成と更新のタイミング
  8. 要件と制限
  9. レコードが表示されない場合

ワークフローにドキュメントの種類を示す名前を付ける

まずこれを行ってください。以下のすべての内容がこれに依存します。

各 Document レコードには、それを生成したワークフローが記録されます。ワークフロー名は、レポートで見積もりと契約書を区別するための手段であり、実質的にドキュメントの種類を表します。ワークフローが「Workflow 1」や「Copy of proposal test」という名前であれば、データの品質がどれほど高くても、レポートは役に立ちません。

ワークフローには生成するドキュメントの名前を付けてください。Quote、Order Form、MSA、NDA、Statement of Work、Invoice、Renewal などです。そうすれば「7 月に署名された契約の件数」は 1 つのフィールドに対するフィルターで絞り込めます。

1 つのワークフローから複数の種類のドキュメントを生成している場合は、ワークフローを分割するか、出力名に種類を含めることで代わりにグループ化できるようにしてください。

ワークフロー名はレコードの Workflow フィールドに記録されます。これはグループ化に使用するフィールドです。

計測できる指標

ドキュメントの種類別の件数

Document レコードをワークフロー別および作成日別にグループ化すると、実際のビジネスの生産量を把握できます。月ごとの見積もり送付件数、四半期ごとの署名済み契約件数、週ごとの請求書発行件数などです。レコードのオーナーを追加すると、担当者ごとの同様の状況が把握でき、「チームが提案書を送付しているか」が印象ではなく数値で確認できます。

見積もりから署名への転換率

同期間に作成された見積もりと署名された契約の 2 つの件数を並べると、ドキュメントベースのクローズ率が得られます。この指標は、誰かが取引ステージをどれだけ丁寧に管理しているかに依存しません。担当者別またはテンプレート別に追跡することで、実際に転換する見積もりを特定できます。

署名にかかる実際の時間

各レコードにはドキュメントの作成日時が記録されており、最後の署名者が完了すると Signed（署名済み）に移行します。この差がお客様の実際の署名サイクルタイムです。取引がひっそりと止まっているのはたいていここです。ドキュメントの種類別に比較してください。NDA の署名に 11 日かかる問題と、MSA の署名に 11 日かかる問題は、性質が異なります。

複数の見積もりがあるのに署名されていない取引

これは、ほとんどのチームが把握できていないレポートです。見積もりワークフローから複数の Document レコードが関連付けられているにもかかわらず、署名済み契約が存在しないソースレコードを探してください。そのような取引はそれぞれ、再交渉、値引き、または停滞が発生していることを示しており、見積もりの件数はその取引が抱えている摩擦の量を示す適切な代替指標となります。値引きレビューのキューであり、コーチングのシグナルでもあります。

ドキュメントと一致しない取引ステージ

ドキュメントと取引が別々のレコードになったことで、両者を相互確認できます。

  • 署名済み契約書がないのにクローズド成立とマークされている取引。これは収益認識と監査上のギャップです。
  • 提案書や交渉ステージにあるにもかかわらず、提案書が一度も生成されていない取引。これはまだ実態のないパイプラインです。

ドキュメントの唯一の証拠が上書きされるプロパティだった場合、どちらも見えません。以下の例では、取引は Closed Won（クローズド成立）とマークされているにもかかわらず、最新の見積もりはまだ Pending（保留中）のままです。

署名者が開封しているかどうか

各レコードには、署名依頼が開封された回数と最終閲覧日時が記録されています。これにより、漠然とした 1 つの問題が、それぞれ異なる対処法を持つ 2 つの問題に分かれます。

  • 送信済みだが、一度も開封されていない。 宛先が誤っているか、迷惑メールフォルダに入っている可能性があります。誰かが再送するか電話をかける必要があり、同じ受信トレイに何度連絡しても解決にはなりません。
  • 5回開封されているのに、まだ署名されていない。 相手はすでに内容を確認しており、何かが妨げになっています。これは異議であり、今日中に電話で対応すべき案件です。

実際に使用されているテンプレート

ワークフロー別に集計した件数を見れば、どのテンプレートが実際に役立っているか、どれが1年間まったく使われていないかがわかります。使われていないものは廃止してください。チームがスクロールしながら見過ごしているショートリストは短くなります。

実行する価値のある自動化

ドキュメントレコードは他のレコードと同様に HubSpot ワークフローに登録し、条件分岐させることができます。そのため、ドキュメントのアクティビティは単なるレポートではなく、実際のプロセスを動かすことができます。設定する価値のある運用例を以下に示します。

  • 契約が署名されたら、納品を開始する。 ステータスが Signed（署名済み）になったら、担当者に通知し、取引ステージを移動させ、オンボーディングタスクを作成して、デリバリーチームに引き継ぎます。署名済みの PDF はすでにレコードに添付されています。
  • 生成に失敗した。 ステータスが Error（エラー）になったら、ドキュメント運用を担当する担当者にアラートを送ります。この設定がなければ、失敗は通知されません。担当者は顧客が見積書を受け取ったと思い込み、顧客は届くのを待ち続けることになります。
  • 送信後2日経っても開封されていない。 ステータスが Signature Requested（署名依頼済み）で閲覧数がまだゼロの場合、電話タスクを作成します。これは一覧の中で最も効果の高い自動化です。顧客の無関心に見えてしまう配信上の問題を検知できるからです。
  • 繰り返し読まれているのに未署名のまま。 閲覧数が3を超えているのに署名がない場合、担当者に電話するよう指示するタスクを作成し、異議の内容を明記します。
  • 未処理の署名を追跡する。 ステータスが Signature Requested または Partially Signed（部分署名済み）のまま通常よりも長い期間が経過している場合、誰かが気づいたときではなく、スケジュールに従ってエスカレーションします。
  • 高額ドキュメントの送信を通知する。 詳細は次のセクションを参照してください。価値は取引側に存在しているためです。
  • 契約更新が近づいている。 下記の契約更新に関するセクションを参照してください。

ドキュメント側か取引側かの自動化

必要なフィールドに応じて、どちらで実行するかを選択してください。

Document（ドキュメント）オブジェクトでワークフローを実行するのは、特定のドキュメント単位の粒度が必要な場合です。つまり、この見積書、そのステータス、閲覧数、送信日時が対象です。上記の運用例のほとんどはこちらに該当します。ドキュメント側のワークフローは Portant Document レコードを登録し、Document Status（ドキュメントステータス）で条件分岐します。そのため、上記の「契約署名済み」の運用例は、登録条件が1つだけで済みます。

deal（取引）でワークフローを実行するのは、金額、パイプライン、ステージなど取引フィールドに基づくルールが必要な場合です。その際は、取引上の Portant ドキュメントステータスプロパティをトリガーとして使用します。「50,000を超える見積書が送信されたらマネージャーに通知する」は取引側のルールです。Document レコードにはドキュメントのステータスとリンクは含まれていますが、金額は含まれていないためです。

ドキュメント自体の金額をレポート対象にしたい場合は、HubSpot capture fields（HubSpot キャプチャフィールド）を使ってプロパティに書き戻すか、金額を取引側に保持してアソシエーションで連携させてください。

契約更新と失効

契約更新はこのページで最も重要な項目であり、Document レコードにはない1つのフィールドが必要です。それは終了日です。レコードにはドキュメントが作成された日時は記録されていますが、契約が失効する日時は記録されていません。終了日を取得する方法は2つあります。

  • 算出する。 ドキュメントの種類に標準的な期間がある場合は、HubSpot ワークフローまたは計算プロパティを使って、作成日にその期間を加算した更新日を設定し、そこから更新タスクを実行します。
  • キャプチャする。 期間が取引ごとに交渉される場合は、署名者にその期間を入力させ、HubSpot capture fields（HubSpot キャプチャフィールド）で書き戻します。

これを署名リンクの有効期限と混同しないでください。署名リンクの有効期限は、未署名の署名リンクがいつまで有効かを制御するものです。あちらはドキュメントへの署名を完了させるための設定であり、こちらは署名が完了した後の契約自体の期間に関する設定です。

この日付が揃えば、すでに生成済みのドキュメントから更新パイプラインを構築できます。今後90日以内に失効する契約、通知期間が近づいている自動更新契約、署名済みの唯一の契約が数ヶ月前に失効しているような顧客などを把握できます。

これにより、このオブジェクトが実用的な軽量の契約ライフサイクル管理の仕組みとして機能します。すべての契約はステータス、署名済み PDF、署名履歴、更新日を持つレコードとして存在し、チームがすでに使用している CRM 内で検索可能です。別の CLM ツールは不要です。条項ライブラリやレッドライニングには対応していませんが、誰と何を署名したか、何が更新を迎えるかを把握するには十分です。

もう1つ挙げておく価値のある用途があります。各レコードが独自のタイムスタンプ、リンク、署名履歴を保持しているため、契約ごとの監査証跡が得られます。調達部門が署名済みのコピーを求めてきた場合や、顧客がどのバージョンに合意したか争いが生じた場合に、まさに必要なものです。

参考情報: 各レコードの内容

各ドキュメントは独自のレコードとして開き、左パネルに Portant プロパティが表示され、Deals（取引）の下にソースレコードが表示されます。

プロパティラベルは、レポートビルダーやワークフローフィルターで選択する際に使用され、レコード上に表示されます。内部名は、HubSpot の API、エクスポート、および統合機能が参照する同一プロパティです。両者は異なるため、ここに両方を記載しています。署名フィールドは特に、画面上では「Signable Document」と表示され、API では signature_request として参照されます。

プロパティラベル 保持する内容 内部名
Document Name ドキュメント名（デフォルトは「Portant Document」） a1323181_document_name
Workflow それを生成したワークフロー、つまりドキュメントの種類 a1323181_workflow_name
Document Status ドキュメントのステータス a1323181_document_status
Document Created Time ドキュメントが作成された日時 a1323181_document_created
Document Link ドキュメントへのリンク（Google Docs または OneDrive） a1323181_document_link
PDF Link PDF へのリンク a1323181_pdf_link
PDF Files 生成された PDF（ファイルとして添付） a1323181_pdf_files
Signable Document Link 署名リクエストへのリンク a1323181_signature_request_link
Signable Document View Count 署名者がそれを開いた回数 a1323181_signature_request_view_count
Signable Document Last Viewed Date 署名者が最後に開いた日時 a1323181_signature_request_last_view_date

プロパティパネルをスクロールすると、署名フィールドおよびそのドキュメントを生成したワークフローが表示されます。

ステータス値は、取引先や連絡先に対する Portant の Document Status プロパティで使用されるものと同じセットです。Pending、Error、Draft、Approved、Signature Requested、Partially Signed、Signed、Sent、Completed の各値があります。

ドキュメントの種類、金額、有効期限のプロパティはありません。種類はワークフロー名から取得され、金額と有効期限は上記で説明したとおり、取引先または取得済みフィールドから取得されます。

レコードが作成および更新されるタイミング

レコードはドキュメント出力が初めて生成されたときに作成され、その後ドキュメントが実行の中で進行するにつれてその場で更新されます。1 つのドキュメントはその全期間にわたって 1 つのレコードに対応するため、レコードを数えることはドキュメントを数えることを意味します。

ステータスは作業の進行に従います。レビュー待ちの下書きは Draft になり、次に Approved、Signature Requested となり、署名者の操作に応じて Partially Signed または Signed となり、メールが送信されると Sent になります。レビューや署名ステップのないワークフローは Completed になります。

1 回の実行で複数の出力を生成するワークフローは、出力ごとに 1 つのレコードを作成し、それぞれが同じソースレコードに関連付けられます。

要件と制限

  • Portant アプリが HubSpot ポータルにインストールされており、HubSpot 接続時にドキュメントオブジェクトの権限が付与されている必要があります。Install the Portant app in HubSpot を参照してください。
  • レコードはドキュメントが生成されるときに作成されます。そのため、Document records が利用可能になる前に生成されたドキュメントは表示されません。バックフィルは行われないため、レポートの履歴は過去に遡るのではなく、開始した時点から蓄積されます。
  • PDF がレコードに添付されるのは、ワークフローが HubSpot へのファイルアップロードを設定している場合のみです。ソースレコードへの添付については View created documents in HubSpot で説明しています。添付されている場合、ファイルとしてレコード上に表示されます。

  • カスタムレポートおよびダッシュボード機能のうちどの機能が利用可能かは、HubSpot のサブスクリプションによって異なります。

レコードが表示されない場合

Portant が Document records を書き込むための権限は HubSpot 接続時に付与されます。そのため、この機能が存在する前に承認された接続にはその権限が含まれていない場合があります。再接続すると HubSpot の権限プロンプトが再実行されます。Reconnect HubSpot の手順に従い、新しいドキュメントを 1 つ生成した後、ソースレコードの関連付けを確認してください。

ドキュメントは正常に生成されるにもかかわらず Document record が表示されない場合は、サポートコードをコピーし、HubSpot ポータル ID を添えてサポートチケットを開いてください。こちら側から接続を確認いたします。