パイプラインレポートを確認するたびに、同じ弱点が見つかります。ステージの情報が古いのです。契約に署名してから2日後も、担当者がカードをボード上でドラッグし忘れたために、案件が「Proposal Sent」に残ったままになっています。些細なミスのように思えますが、これが予測を狂わせ、ベロシティの数値を不正確にし、パイプラインレビューを当て推量のゲームにしてしまいます。
シンプルな解決策があります。人間に案件ステージの更新を任せる代わりに、ドキュメント自体がその移動をトリガーするようにするのです。提案書が送付されると、案件は「Proposal Sent」に進みます。署名リクエストが送信されると、「Contract Sent」に移動します。ドキュメントに署名されると、案件は「Closed Won」に移動します。記憶力は不要です。
ここでは、PortantのDocument Statusプロパティと標準的なHubSpotワークフローを使って、HubSpotで案件ステージの自動進行を設定する方法を説明します。パイプラインが常に現実より数日遅れているように感じる場合、おそらくこれが原因です。
手動による案件ステージ更新が失敗する理由
担当者は忙しいものです。電話対応、メール作成、購買担当者へのフォローアップに追われています。案件ステージの更新は、営業そのものに何の価値も付加しない優先度の低い作業です。そのため、スキップされたり、後回しにされたり、週末にまとめて処理されたりします。
その影響は、多くのリーダーが気づいている以上に大きいものです。5人の担当者がそれぞれ週に3件の案件更新を忘れると、常時15件の案件が誤ったステージに放置されることになります。パイプラインレポートが経営陣に伝えるストーリーと、現実のそれが食い違ってしまいます。
予測はステージに依存しています。予測モデルがステージの確率によって案件を重み付けしている場合、古いステージは不正確な数値を生み出します。実際にはクローズ済みなのに「Contract Sent」のまま表示されている案件は、クローズ済み売上を過小評価します。提案にエラーが発生したにもかかわらず「Proposal Sent」のまま表示されている案件は、パイプラインを過大評価します。どちらも問題です。
解決策は、より厳しい規律でも、別のSlackリマインダーでもありません。外部でイベントが発生するたびに人間がCRMフィールドを確実に更新するよう訓練することは不可能です。解決策は、手動のステップを完全に排除し、イベント自体が更新をトリガーするようにすることです。
パイプラインシグナルとしてのドキュメントライフサイクル
PortantをHubSpotと併用すると、Portantは生成したすべてのドキュメントを、案件上の独自レコード（カスタムオブジェクト）として保存します。そのレコードはDocument Statusというプロパティを持ち、ドキュメントがライフサイクルを通じて進行するにつれて自動的に更新されます。
これこそがパイプラインに必要なシグナルです。担当者に受信トレイを確認してからHubSpotを更新するよう求める代わりに、実際に何かが起きたときにDocument Statusプロパティが自動的に変化します。ドキュメントが送付される。署名がリクエストされる。ドキュメントに署名される。何か問題が発生する。これらのステータス変化はそれぞれ、営業プロセス上の実際の出来事に対応しています。つまり、それぞれが案件ステージに直接マッピングできるということです。
関連記事として、how to align deal stages with document typesを執筆しました。ステージとドキュメントの概念的なマッピングについて解説しています。この記事はさらに一歩進み、そのアラインメントを自動化することでパイプラインが自己更新されるようにします。
PortantのDocument Statusの値
PortantのDocument Objectは9つのステータス値を追跡します。それぞれの意味と適用タイミングについて説明します。
- Pending：Portantがドキュメントレコードを作成しましたが、生成はまだ開始されていません。
- Draft：Portantがドキュメントを生成しましたが、まだ下書き段階で最終版ではありません。
- Approved：チームが社内でドキュメントをレビューし、承認しました。Portantのapproval workflowsを使用している場合に適用されます。
- Sent：Portantが受信者にドキュメントを送付しました。
- Signature Requested：Portantが署名者（一名または複数名）に電子署名リクエストを送信しました。
- Partially Signed：少なくとも1名の署名者が署名を完了しましたが、残りの署名者はまだです。
- Signed：すべての署名者が署名を完了しました。
- Completed：署名後のステップを含め、ドキュメントのライフサイクルが完了しました。
- Error：生成、送付、または署名のプロセス中に問題が発生しました。
すべての案件が9つのステータスすべてを通過するわけではありません。シンプルな見積書であれば、署名を必要とせずにPendingからSentに移行することもあります。契約書であれば、Sent、Signature Requested、Partially Signed、Signed、Completedを経由することもあります。構築するワークフローは、実際のプロセスで重要なステータスを考慮したものにする必要があります。
これらのプロパティの詳細については、Portant documentation on triggering HubSpot workflows from document status changesをご参照ください。
ワークフローの構築
設定にはHubSpotの標準ワークフローツールを使用します。関連するPortant Document ObjectのDocument Statusプロパティの変化をトリガーとする、案件ベースのワークフローを作成します。
ほとんどの営業プロセスにおいて推奨するコアマッピングは以下のとおりです。
ワークフロー1：Document Sent → 「Proposal Sent」に移動
- HubSpotで「Automation」>「Workflows」に移動します。
- 新しい案件ベースのワークフローを作成します。
- 登録トリガーを次のように設定します：Associated Portant Document Object > Document Status が「Sent」である。
- アクションを追加します：Set deal property > Deal Stage を「Proposal Sent」（または同等のステージ名）に設定する。
- 保存してオンにします。
Portantが提案書または見積書を購買担当者に送付すると、Document Statusが「Sent」に変化します。このワークフローがその変化を検知し、案件を自動的に前進させます。
ワークフロー2：Signature Requested → 「Contract Sent」に移動
同じ構造で、トリガーが異なります。
- 登録トリガー：Document Status が「Signature Requested」である。
- アクション：案件ステージを「Contract Sent」に設定する。
これは署名プロセスが開始された瞬間をカバーします。購買担当者は電子署名リクエスト付きのドキュメントを受け取っており、案件ステージもそれを反映すべきです。
ワークフロー3：Signed または Completed → 「Closed Won」に移動
- 登録トリガー：Document Status が「Signed」または「Completed」である。
- アクション：案件ステージを「Closed Won」に設定する。
プロセスの仕組みによって、「Signed」または「Completed」のいずれかを使用できます。案件をクローズする前に署名後のすべてのステップを完了させる必要がある場合は「Completed」をトリガーにします。最後の署名がクローズイベントである場合は「Signed」をトリガーにします。
ワークフロー4：Error → 案件オーナーに通知
- 登録トリガー：Document Status が「Error」である。
- アクション：案件オーナーに次のようなメッセージで社内通知を送信する：「[Deal Name]のドキュメントにエラーが発生しています。ドキュメントを確認し、必要に応じて再送してください。」
このワークフローが重要なのは、アラートがなければエラー状態が見えないままになるからです。契約書の生成に失敗したことや、署名リクエストがバウンスしたことに担当者が気づかない場合があります。即時通知により、案件がサイレントに停滞するのを防げます。
代替案：分岐を持つ単一ワークフロー
管理するワークフロー数を減らしたい場合は、Document Statusの値を確認して適切なアクションにルーティングするIf/Then分岐を持つ単一の案件ベースワークフローを作成することもできます。ロジックは同一で、整理の仕方が異なるだけです。私は通常、デバッグしやすいため別々のワークフローから始め、チームがよりシンプルなビューを望む場合は後で統合します。
パイプラインの可視性向上のための案件タグ追加
案件タグは、HubSpotのボードビューで案件カードに表示されるカラーコードのラベルです。担当者やマネージャーが各案件を開かずにパイプラインをスキャンする際、素早い視覚的指標を提供します。
Portantでは、Document Statusに基づいて案件タグを追加できるため、パイプラインボードで各案件がドキュメントライフサイクルのどの段階にあるかが一目でわかります。例えば、以下のように設定できます。
- 「Signed」の案件に緑のタグ
- 「Signature Requested」の案件に黄色のタグ
- 「Error」の案件に赤のタグ
- 「Sent」の案件に青のタグ
これはパイプラインレビューで特に役立ちます。各案件のドキュメントの進捗を確認するためにクリックして開く代わりに、マネージャーはボードをスキャンするだけで、停滞している署名やすり抜けたエラーなど、対応が必要な案件をすぐに把握できます。
設定手順については、Portantのドキュメントステータスを使用したディールタグの追加に関するガイド.
想定すべきエッジケース
どの自動化も初日から完璧に機能するわけではありません。チームがつまずきやすい状況と、それぞれの対処法をご紹介します。
1件のディールに複数のドキュメントがある場合
1件のディールに見積書、提案書、契約書がそれぞれ存在し、それぞれ独自のDocument Statusを持つ場合があります。見積書が「Completed」でも契約書が「Pending」の場合、どのステータスがディールステージを決定すべきでしょうか。
推奨事項として、最新ドキュメントのステータスを主要なシグナルとして使用してください。一貫した命名規則を採用している場合、ワークフローの登録条件でドキュメントテンプレートまたは名前によるフィルタリングが可能です。テストが必要ですが、正しく設定することで、契約書がまだ送付されていない段階で完了済みの見積書によってディールが早期にクローズされる事態を防げます。
再送された提案書
購買担当者からの変更依頼により担当者が提案書を再送した場合、Document Statusは再び各値を巡回します。新しい「Sent」ステータスが別のドキュメントに表示された際にディールステージが正しく更新されるよう、ワークフローで再登録に対応する必要があります。
これによりディールがパイプラインで後退する可能性があることにご注意ください。契約書がすでに進行中の状態で新しい提案書が送付された場合、ディールが「Proposal Sent」に戻ることがあります。ワークフローでステージを前進方向のみに移動させ、後退は許可しない設計が適切かどうかを検討してください。多くのチームに対し、前進のみのロジックを採用し、後退が必要な場合は別途専用のワークフローを設けることを推奨します。
エラー状態
エラーが発生したからといって、ディールが失注したわけではありません。テンプレートの差し込み処理の失敗や署名サービスのタイムアウトなど、技術的な問題が発生したことを意味します。Workflow 4の通知ワークフローがここでのセーフティネットとなります。通知には、担当者が対応できる十分な情報（ディール名、ドキュメント名、Portantでステータスを確認するための案内）が含まれていることを確認してください。
部分的に署名されたドキュメント
複数の署名者が必要な契約書の場合、「Partially Signed」は有用な中間ステータスです。専用のディールステージが不要な場合でも、「Awaiting signatures」のようなディールタグを設定することで、どの契約書が進行中でどれが特定の署名者待ちになっているかをマネージャーが把握しやすくなります。
パイプラインレポートへの効果
実際のドキュメントイベントに基づいてディールステージが自動的に更新されると、以下の3点が改善されます。
予測精度。ステージは担当者が記録した内容ではなく、実際に発生したことを反映します。予測モデルがステージ確率を使用している場合、それらの確率は先週金曜日のデータクリーンアップ時の推測ではなく、現実に基づくものになります。
パイプラインの進捗速度。ステージ滞在時間の指標が有意義なものになります。「Proposal Sent」から「Contract Sent」までの実際の所要時間を計測できます。両方の移行がドキュメントイベントに紐づいており、手動操作に依存しないためです。これにより、ディールが滞る箇所に関する実データが得られます。
パイプラインの健全性。停滞しているディールの特定が容易になります。あるディールが「Contract Sent」のまま2週間が経過し、Document Statusが依然として「Signature Requested」を示している場合、問題はデータではなくディール自体にあります。マネージャーはパイプラインレビューをデータ入力の確認ではなく、コーチングに集中できます。
一度設定すれば、パイプラインを通過するすべてのディールで、誰も意識することなくより正確なステージが反映されます。
始め方
すでにPortantとHubSpotを連携してご利用の場合、Document Statusプロパティはすでにドキュメントレコード上に存在しています。上記で説明した4つのコアワークフローから始めてください。全チームへ展開する前に、少数のディールでテストを行うことをお勧めします。
ステージとドキュメントの概念的な接続についてより深く理解したい場合は、ディールステージをドキュメントタイプにマッピングする方法に関する以前の記事をご覧ください。
Portantをまだご利用でない場合は、HubSpot連携ページで機能の詳細と設定方法をご確認ください。
よくある質問
HubSpotのすべてのディールパイプラインで使用できますか？
はい。ワークフローは関連するPortant Document ObjectsのDocument Statusプロパティをトリガーとしており、特定のパイプラインに紐づいていません。ワークフローの分岐を使用することで、パイプラインごとに異なるステージマッピングを設定できます。
ディールステージがサンプルと異なる場合はどうすればよいですか？
マッピングは完全に柔軟に設定できます。例として使用した「Proposal Sent」「Contract Sent」「Closed Won」は一般的なラベルですが、Document Statusの変更を実際のパイプラインで使用しているステージにマッピングしてください。重要なのは、各ステータスの変更がプロセスにとって意味のあるステージ移行に対応していることです。
手動によるステージ変更が上書きされることはありますか？
ワークフローの設定方法によって異なります。担当者がドキュメントの署名前に手動でディールを「Closed Won」に移動した場合、そのように設定しない限りワークフローは元に戻しません。ステージを前進方向のみに移動させるワークフローを構築することを推奨します。後退が必要な場合は、追加の保護措置とチーム向けの明確なドキュメントを備えた別のワークフローとして追加してください。
承認ワークフローと併用できますか？
はい。チームがPortantの承認ワークフローを使用している場合、内部レビュー後にDocument Statusが「Approved」に更新されます。それに応じてディールを「Pending Send」や「Ready for Buyer」などのステージに移動させるワークフローを追加できます。これは、提案書をクライアントに送付する前にマネージャーの承認が必要なチームに有用です。
