HubSpotで見積もりを自動化しましょう。

見積書の価格ミスは、提案書の価格ミスよりも大きな損失をもたらします。提案書は説得のための文書です。見積書はコミットメントの文書です。数字が間違っていれば、利益を削るか、すでに不利な状況で交渉をやり直すかのどちらかになります。それでも、ほとんどの HubSpot チームは今も同じやり方で見積書を作成しています。スプレッドシートをコピーし、明細項目を貼り付け、書式を整え、PDF に書き出し、メールで送り、火曜日以降に価格表が変わっていないことを祈るだけです。

このパターンが3つの予測可能な形で崩壊するのを目の当たりにしてきました。まず、担当者が最新の価格を確認しようとしたり、マネージャーの割引承認を待ったりするため、見積もりの作成に2〜3日かかってしまいます。その間に、購買担当者の反応が途絶えてしまいます。次に、担当者がv2を送付したにもかかわらず、購買担当者はv1を確認し、財務部門はv3を承認するといった具合に、複数のバージョンが混在してしまいます。そして3つ目として、見積もりの数字がHubSpotに登録されている内容と一致しないため、案件がクローズした時点から売上レポートに誤りが生じてしまいます。

このプレイブックでは、3つの問題をすべて解決する方法をご紹介します。Portantで見積もりワークフローを構築し、HubSpotから案件データと明細項目を直接取得して、ブランド化されたテンプレートに統合し、PDFとして出力します。また、必要に応じて購買担当者が確認する前にレビュープロセスを経由させることもできます。すべての数値はCRMに紐付けられています。すべての見積もりはバージョン管理されています。すべての出力はファイルに保存されます。

It looks like your message got cut off. Could you please share the English text you'd like me to translate? Once you provide the full content (including any ` __PORTANT_T_SPLIT__ ` markers), I'll translate it into Japanese following all the rules. HubSpot向け見積もり自動化。自動化の前にCRMのデータ品質を整えるために、 HubSpot データを監査して正確なドキュメントを作成 時間をかける価値があります。

ブログの他の記事： 正確な見積もりのための HubSpot 明細項目, ネイティブの HubSpot 見積もりでは物足りなくなったとき、および ネイティブの引用符を置き換えても制御を失わない.

優れた見積もりワークフローとはどのようなものか

ステップごとの説明に入る前に、完成した状態をイメージしておくと理解しやすくなります。機能する見積もりワークフローは次のようなことを実現します。

1. 担当者がHubSpotで案件を開きます。案件には明細項目（製品、数量、単価、割引）とヘッダーレベルのプロパティ（案件金額、クローズ日、担当者名、支払条件）が含まれています。
2. 取引レコードから、担当者が Portant ワークフローをトリガーします。Portant は取引のプロパティと、関連するすべての明細項目を読み取ります。
3. これらの値はGoogle DocsまたはSlidesのテンプレートに差し込まれます。ヘッダーフィールドはドキュメントの上部に入力されます。明細項目は価格表に展開され、製品ごとに1行ずつ、数量、単価、割引、明細合計の列が設けられます。
4. 出力はPDFです。購入者はレイアウトが固定されたファイルを受け取り、そのまま調達部門に転送したり、発注書に添付したりすることができます。再エクスポートの前に手動で調整が必要な場合に備え、編集可能なDocはDriveに保存されたままになります。
5. HubSpotのレコードには、送信内容と送信日時が正確に表示されます。PDFは案件に添付されます。Portantの出力ページには、すべてのバージョンのログが記録されます。

それが目標です。スプレッドシートも、コピー＆ペーストも、バージョンの混乱もありません。CRM が唯一の情報源となり、ドキュメントはその内容を正確に反映します。

このプレイブックの内容

• 取引プロパティと明細プロパティを1つのテンプレートにマッピングする
• 複数の明細項目を1つのテーブルに表示し、行を自動的に拡張する
• 購入者が期待する形で見積書が表示されるよう、明細項目のプロパティを並べ替えて選択する
• HubSpot のディールレコードから見積もりを生成する
• 顧客向けファイルのPDF出力を作成する
• 標準外の価格設定に対するレビューゲートの追加
• 取引ステージの変更から見積書生成を自動化する
• エッジケースの処理：複数通貨、カスタム明細項目プロパティ、空フィールド

ステップ1：取引内容に合わせた見積書テンプレートをデザインする

PortantでHubSpot Dealsをソースとしてワークフローを作成します。これにより、ワークフローが取引レコードに接続され、すべての取引プロパティ、関連する連絡先および会社のプロパティ、明細項目のプロパティがマージトークンとして利用可能になります。

テンプレートには、ヘッダーと料金表の2つのゾーンがあります。

ヘッダーフィールド

ヘッダーとは、明細項目テーブルより上のすべての内容を指します。ほとんどの見積書に必要な要素は以下のとおりです。

• 会社名 関連する会社オブジェクトから
• 連絡先名およびメールアドレス 関連する連絡先から
• 案件名 見積もりのタイトルまたは参照として
• 取引金額 見積もり合計として
• 締切日 見積有効期限または意思決定予定日として
• 取引担当者名 そのため、購入者は誰に電話すればよいかを把握できます。
• 支払い条件 これらをディールプロパティとして保存する場合（Net 30、Net 60 など）

これらのトークンをGoogle DocまたはSlidesテンプレートの上部セクションに配置してください。各トークンはHubSpotのプロパティに対応しており、ワークフローが実行されると値が自動的に入力されます。

Google Docs と Slides の選び方

Google Docsは、価格表が中心となるテキスト中心の見積書に適しています。自然なページフロー、簡単な書式設定、そして明細項目が増えても表がきれいに拡張される点が特長です。一方、Google Slidesは、ブランドの背景やロゴを固定位置に配置したデザインPDFのように、見積書がよりビジュアル重視の場合に適しています。コンテンツの長さに関わらず、レイアウトを常に同じ見た目に保つ必要がある場合に最適です。

ほとんどの見積もりワークフローには、Docsをお勧めします。テーブルの展開動作がより予測しやすく、見積もりはレイアウトよりも数字が本質だからです。

これが初めての HubSpot を活用したワークフローであれば、さっと目を通してください HubSpot ソースドキュメント および データマージ プロパティ選択パターンのため。

ステップ2：1つのドキュメントに複数の明細項目を追加する

これは見積もりの自動化を実際に機能させるステップです。案件に複数の商品が含まれる場合、Portantはテーブルの行を繰り返すことで、各明細項目が出力内で独自の行を持つようにします。ドキュメントの記事 複数の明細項目を1つのドキュメントにまとめて追加する 正確なレイアウトを表示します。

テーブル展開の仕組み

テンプレートでは、2つの概念的な部分からなる表を作成します。

1. Please provide the text you'd like me to translate. It seems the actual content is missing from your message. 「Product」「Qty」「Unit Price」「Discount」「Total」などの固定列ラベルは、差し込みトークンを含まず、すべての出力で変わらず表示されます。
2. It looks like your message contains only "The data row:" with no actual text segments to translate, and no ` __PORTANT_T_SPLIT__ ` marker. Could you please provide the full text you'd like translated, including all segments separated by ` __PORTANT_T_SPLIT__ `? ヘッダーの下に1行だけ、明細項目のトークンを含む行を配置します。列ごとに1つのトークンを配置します。商品名トークン、数量トークン、単価トークンなど、それぞれの列に対応するトークンを入力してください。

ワークフローが実行されると、Portantは案件に含まれる明細項目の数を読み取ります。製品が5つある場合、そのデータ行をさらに4回複製し、各コピーに対応する明細項目の値を入力します。製品が1つの案件では1行のテーブルが生成され、製品が15個の案件では15行のテーブルが生成されます。テンプレートはどちらの場合も変わりません。

含める列の選択

典型的な見積もり表には、5〜7列が含まれます。以下は、基本的なデフォルト構成の例です。

• I notice the text to translate appears to be incomplete - "Product name:" seems to be just a label without any actual product name following it. Could you please provide the complete text you'd like translated into Japanese? I'll be happy to help once I have the full content to work with. 購入者が受け取るもの
• Please provide the English text you would like me to translate into Japanese. You've only included "Description:" without any actual content to translate. 一行の概要（任意、製品名が自明な場合はスキップ可）
• 数量： 何単位
• 単価： 割引前の単価
• 割引： 割引率または割引額（該当する場合）
• 行合計： その行の正味金額

定期請求と一回限りの請求が同じ取引に含まれる場合は、「請求頻度」列を追加して、購入者がどの料金が繰り返し発生するかを確認できるようにしましょう。

テーブル展開でよくある落とし穴

セルの結合により、展開機能が正常に動作しなくなります。 テンプレートテーブルのデータ行でセルを結合すると、Portant はその行を確実に複製できません。データ行はシンプルな結合なしのセルを維持してください。ヘッダー行やテーブル下の集計行ではセルを結合できますが、繰り返し行はクリーンな状態にする必要があります。

テンプレートテーブル内の数式は引き継がれません。 Google Sheets 形式の数式を Docs のテーブルセルに入力しても、出力では計算されません。値は HubSpot から取得されます。合計行が必要な場合は、テンプレートで品目行を合計しようとするのではなく、テーブルの下にあるディール単位の金額プロパティを使用してください。

空の品目は空の行を生成します。 ディール上に品目が存在しても価格や数量がない場合、空のセルを含む行が生成されます。ワークフローを実行する前に HubSpot で孤立した品目を整理するか、エッジケースの出力に簡単な手動クリーンアップが必要になる場合があることを了承してください。

ステップ 3: プロパティ管理で行の順序を制御する

行の順序は、他のどのドキュメントタイプよりも見積書において重要です。購入者は見積書を上から下へと読み進め、合計金額に辿り着く前に期待値を形成します。品目がランダムな順序で表示されると、見積書は雑然とした印象を与えます。割引が適用対象の品目より先に表示されると、価格の説明が一貫しなくなります。

推奨されるデフォルトの並び順

ほとんどの B2B 見積書では、次の順序が読みやすいです。

1. コア製品またはプラットフォーム料金 を最初に。購入者が主に購入するものです。
2. アドオンまたはシートライセンス を次に。コアを拡張する二次的な品目です。
3. 導入またはオンボーディング費用 をその下に。まとめて記載する一時的な費用です。
4. 割引 を最後に。購入者は何が差し引かれるかを見る前に、何を得られるかを確認できます。

Portant の HubSpot プロパティ管理 UI を使用して、表示したい順序に品目を並べ替えてください。ドキュメントには、品目ガイドと以下のスクリーンショットが掲載されています。 HubSpot プロパティを管理・選択する方法.

適切なプロパティの選択

テンプレートで実際に使用するプロパティのみを公開してください。テンプレートに 6 列ある場合は、6 つの品目プロパティを選択します。20 のプロパティを公開してもそのうち 6 つしか使用しない場合、Portant ビルダーはテンプレートにドラッグすることのないトークンで乱雑になります。さらに悪いことに、担当者が意図しないトークンを誤って使用すると、計画していないデータがドキュメントに入り込みます。

一方で、プロパティを少なく選びすぎることも簡単に起こるミスです。テンプレートが「Billing Frequency」トークンを参照しているのに、ソース設定でそのプロパティを選択していなかった場合、トークンは出力で空白のテキストとして表示されます。ドキュメントが壊れているように見え、担当者はその原因を調べなければなりません。

ステップ 4: ディールレコードから見積書を生成する

担当者は見積書を作成するために HubSpot を離れるべきではありません。CRM 連携ドキュメントの目的は、担当者が自分のワークスペースにとどまれることにあります。

担当者の視点から見たフローは次のとおりです。

1. HubSpot でディールレコードを開きます。
2. 右サイドバーで Portant カードを見つけ、見積書ワークフローを選択します。
3. ディールに複数の関連コンタクトがある場合は、適切なコンタクトを選択します。これは見積書では重要です。同じディールに技術担当者、請求担当者、意思決定者がいる場合があります。選択したコンタクトによって、見積書のヘッダーに表示される氏名とメールアドレスが決まります。
4. 確認して実行します。Portant はディールを読み取り、品目を取得し、すべてをテンプレートに差し込んで出力を生成します。
5. 完成した見積書はディールの Portant カードに表示されます。担当者はプレビュー、PDF のダウンロード、または直接送信が可能です。

実際の関連オブジェクト

「関連オブジェクト」という言葉は、3 つのコンタクトと 2 つの会社が紐づいたディールを前に眺めるまで抽象的に感じられます。見積書においては、関連付けの選択は実用的です。この見積書は誰宛てに送るのか、ということです。

ディールに単一の主要コンタクトがある場合、Portant は自動的にそのコンタクトのデータを使用します。複数のコンタクトがある場合は、1 人を選択します。選択したコンタクトがテンプレート内のコンタクトレベルのトークン（氏名、メールアドレス、電話番号、役職）に入力されます。会社の関連付けも同様に機能します。

B2B 見積書でよくあるパターン: ディールが会社（請求先住所と正式名称のため）と特定のコンタクト（「宛先」欄のため）に関連付けられています。生成する前に、両方の関連付けがディールに存在することを確認してください。

全ステップ一覧: HubSpot でドキュメントを作成する.

ステップ 5: 顧客向けファイルの PDF 出力をオンにする

見積書は PDF で届けるべきです。Google Doc のリンクは社内向けに感じられます。PDF は公式な印象を与えます。購入者は、調達部門に転送したり、発注書に添付したり、自社システムで保管したりできる固定レイアウトのドキュメントを期待しています。

PDF のみ vs PDF と編集可能な Doc の両方

2 つの選択肢があります。

• PDF と編集可能な Doc の両方（デフォルト）: Portant は両方を生成します。PDF は顧客に送付されます。編集可能な Doc は、再エクスポート前に手動で微調整が必要な場合に備えて Drive に保存されます。これは、生成後に見積書を調整することがあるチームにとってより安全な選択肢です。
• PDF のみ: Portant は PDF のみを生成します。見積書が完全に標準化されており、生成後に編集することがない場合に使用します。Drive をよりシンプルに保てます。

いずれの場合も、ワークフローがそのように設定されていれば、PDF は HubSpot のディールに添付されます。つまり、チームの誰がディールを開いても、何が送付されたかを正確に確認できます。

ファイルの命名規則

出力ファイルは後で見つけやすい名前を付けてください。推奨されるパターンは [Company Name] - Quote - [Deal Name] - [Date]です。Portant ワークフローでトークンを使用してこれを設定できるため、各出力は CRM データから自動的に名前が付けられます。担当者が半年後に Drive を検索したり HubSpot のアクティビティタイムラインを確認したりする際に、ファイル名を見るだけで何を見ているかが分かり、開く必要がありません。

「Quote」や「Document1」のような一般的な名前は避けてください。四半期内に数百件が作成され、見分けがつかなくなります。

ステップバイステップ UI と PDF のみモード: PDF 出力を作成する.

ステップ 6: 割引および非標準条件の承認レビューを追加する

すべての見積書にレビューが必要なわけではありません。価格が標準的で、割引ポリシーが厳格で、テンプレートが十分にテストされていれば、担当者はレビューなしで生成・送付できます。しかし、特定の見積書は必ず第三者の目を通すべきです。

レビューが重要な場合

• 非標準割引: 事前承認済みの割引しきい値を超えるもの
• カスタム条件: 標準の Net 30 と異なる支払条件
• 大型ディールの金額: VP または財務部門の承認が必要な一定金額を超える見積書
• 新製品またはカスタムバンドル: 標準の見積書プロセスを経ていない品目

Portant ワークフローのドキュメントブロックの後に Review ブロックを追加してください。承認者を割り当て、営業リーダーと財務部門の両方がファイルを承認する必要がある場合は全員の承認を必須にします。ドキュメントは全員が承認するまで「承認待ち」の状態になります。承認されて初めて送付可能になります。

承認しきい値の設定

最もシンプルなアプローチ: 2 つの見積書ワークフローを作成します。1 つは標準価格用（レビューなし、担当者がすぐに生成・送付）、もう 1 つは非標準価格用（レビュー必須）です。担当者はディールに応じて適切なワークフローを選択します。以下も活用できます。 ワークフローフィルター 取引金額やその他のプロパティに基づいて取引をルーティングするため。

条件付きレビューを含む単一ワークフローを希望するチームには、取引金額または割引率によってレビューブロックを有効化するかどうかを制御できます。これにより、テンプレートを1つに保ちながら、数値が必要と判断した場合にのみ承認ゲートを追加できます。

製品の動作は以下に記載されています 文書のレビューと承認. HubSpot を一日中使っている承認者の方々にとって、 HubSpotでドキュメントをレビューおよび承認する モーダルと下書きステータスのフローについて説明します。

見積もり生成の自動化

取引カードからの手動生成は、最初のステップとして最適です。しかし、テンプレートが安定し、データが整ったら、取引が特定のステージに達したときに自動的に見積書を生成するよう設定できます。

取引ステージの変更をトリガーにする

HubSpot でワークフローを作成し、「Quote Requested」または「Proposal Sent」ステージ（購入者が価格を求めているステージ）にディールが移行した際に登録されるよう設定します。見積もりワークフローを対象とする Portant アクションを追加してください。担当者がディールをそのステージに移動させると、見積書が自動的に生成されます。

いくつかのガイドラインを設定します。

• 再登録をオフにします。 商談がステージ間を行き来するたびに新しい見積書を作成したくはないはずです。通常、1件の商談につきトリガーは1回が適切です。
• 少し遅延を追加します。 担当者がステージを変更した後、明細項目と取引先担当者の関連付けが確定するまで、30秒から60秒の猶予を設けてください。5秒の遅延では、担当者が最後の製品を追加し終わる前に見積書が生成されてしまう可能性があります。
• レビューをオンのままにしてください。 自動生成にレビューなしを組み合わせると、誰も確認しないまま見積もりが送られてしまいます。完全に標準的な取引であればそれで問題ありません。それ以外のすべての案件には、レビューの承認ステップを残しておきましょう。

自動化すべき場合と手動のままにすべき場合

案件が標準化されている場合に自動化を活用しましょう。固定価格表、一貫した明細項目、整理されたCRMデータ、そして十分にテスト済みのテンプレートが揃っている場合が該当します。案件が複雑であったり、カスタム対応が必要であったり、担当者が見積書の宛先となる取引先担当者を選択する必要がある場合は、手動対応を維持してください。

多くのチームは両方を活用しています。標準的な取引（一定の規模以下、標準製品、標準条件）は自動的にトリガーされます。複雑な取引（エンタープライズ価格設定、カスタムバンドル、複数年契約）は、担当者がタイミングや関連付けを完全にコントロールできるよう、手動のままにしておきます。

ドキュメントタイプ全体にわたる商談ステージの規律について詳しくは、こちらをご覧ください ドキュメントワークフローのためのディールステージ.

エッジケースへの対応

基本的なフローは見積もりの80%に対応できます。残りの20%こそ、チームが行き詰まりやすい部分です。よくあるエッジケースへの対処法をご紹介します。

マルチ通貨取引

HubSpot ポータルが複数通貨に対応している場合、明細項目の価格は取引の通貨で保存されます。Portant は HubSpot が返す値をそのままマージするため、EUR の取引では EUR 金額の見積書が生成されます。注意すべき点として、テンプレートに通貨記号またはコードが表示されるよう設定してください。「5,000」とだけ記載された見積書では、「EUR」や「$」がなければ金額が曖昧になります。テンプレートのヘッダーや合計金額の横に、取引の通貨プロパティをトークンとして使用してください。

カスタム明細プロパティ

HubSpotでは、明細項目にカスタムプロパティを作成できます。導入費用、サポートティア、請求頻度、契約期間など、これらはすべてプロパティ管理ステップで選択することで、Portantのマージトークンとして機能します。明細項目にカスタムの「Implementation Fee」プロパティを追加した場合は、Portantのソース設定でそれを選択し、テンプレートテーブルに対応する列を追加してください。

注意点として、カスタムプロパティは入力が一貫しないことが多いです。入力する担当者もいれば、しない担当者もいます。明細項目のプロパティが空の場合、出力の該当列はその行で空白になります。カスタムプロパティが見積もりに必須かどうかを事前に決定し、HubSpot の必須フィールドまたは検証ルールで徹底するようにしてください。

定期請求と一回限りの明細項目

定期請求と一時請求が混在する案件では、その違いを明確に示す見積書が必要です。有効なアプローチが2つあります。

• 請求頻度の列を追加する テーブルに追加されます。各明細行には「Monthly」、「Annual」、または「One-time」が表示されるため、購入者はその違いをインラインで確認できます。
• 2つのテーブルに分割します。 定期請求用のテーブルと一度きりの請求用のテーブルをそれぞれ用意します。テンプレートはやや複雑になりますが、異なる請求を別々の予算ラインに振り分ける必要があるエンタープライズ向けの購買担当者にとって、より読みやすい構成となります。

会社データがディールに含まれていません

見積書に必要なデータが、取引ではなく会社レコードに存在する場合があります。請求先住所、法人名、VAT番号などがその例です。Portantでは、取引が会社に関連付けられている場合、会社レベルのプロパティをトークンとして利用できます。それらを取引にコピーする必要はありません。関連付けが存在することを確認し、ソース設定で会社プロパティを選択するだけです。

空欄フィールドと不足データ

取引プロパティが空の場合、出力内のトークンは空白テキストとして表示されます。「支払条件」のようなヘッダーフィールドでは、条件が表示されるべき箇所に空白行が生じます。「割引」のような明細列では、テーブル行内のセルが空になります。

これが常に問題になるわけではありません。すべての案件に割引があるわけではないからです。しかし、会社名や取引金額などの必須フィールドに空白の値がある場合、それはデータの上流に何らかの問題があることを意味します。解決策はテンプレートのロジックではなく、データの整合性を保つことです。案件が見積もり段階に達する前に、CRMのプロセスで必須フィールドへの入力を徹底させてください。

テンプレートデザインのベストプラクティス

適切に設計されたテンプレートは、明細項目が1行でも20行でも崩れることなく対応できます。以下の点を念頭に置いてください。

列幅の統一

製品名列の幅は、最も長くなり得る値に対応できるよう設定してください。製品名は長くなる場合があります（例：「Enterprise Platform License, Annual Subscription, 50-Seat Bundle」）。製品名列が狭すぎると、テキストが不自然に折り返され、表全体が窮屈な印象になります。製品名列にはテーブル幅の40〜50%を割り当ててください。数量・単価・合計などの数値列は、数字がコンパクトであるため、より狭い幅で問題ありません。

異なるディール規模でのテスト

公開する前に、3つの案件でテストしてください。

1. 1つの明細項目を含む取引。 見積書が1行のテーブルで正しく表示されていますか？空白が多すぎると感じませんか？
2. 5つの明細項目を含む取引。 平均的なケース。テーブルはきれいに流れていますか？
3. 15から20の明細項目がある取引。 表がページをまたいで2ページ目に続いていますか？その場合、改ページの位置は適切ですか？価格表が2ページ目に続く際、1ページ目のヘッダーフィールドは引き続き意味をなしていますか？

この3件の取引テストにより、実際のバイヤーが目にする前に、ほとんどのレイアウトの問題を発見できます。

利用規約

多くのチームは、別の書類ではなく見積書自体に利用規約を掲載することを希望します。料金表の下に標準条件を記載した静的セクションを追加することができます。条件が異なる案件（エンタープライズと標準、管轄区域の違いなど）については、条件付きセクションの使用または2つのテンプレートバリアントの管理をご検討ください。

サマリーセクション

明細テーブルの下に、取引レベルの合計金額、取引レベルの割引（該当する場合）、税金（該当する場合）、および総合計を含むサマリーブロックを追加してください。これらの値は、テンプレート内の明細項目の計算からではなく、取引プロパティから取得してください。HubSpot の取引金額が正式な数値となります。明細項目の合計と一致しない場合、それはテンプレートではなく CRM 内で修正すべきデータの問題です。

よくあるミス

基本的なフローは動作しているのに、本番環境で問題が発生してチームが躓くケースをよく見かけます。

明細項目のプロパティの選択が正しくありません

最もよくある間違いです。明細の合計金額列にテンプレートで「Amount」を設定したのに、ソース設定では「Price」を選択してしまうケースです。「Price」は単価を指し、「Amount」は数量に単価を掛けた金額を指します。出力される数値は HubSpot の定義上は正しいのですが、担当者が意図したものとは異なります。選択したプロパティがテンプレートの各列に期待する値と一致しているか、必ず二重確認してください。

購入者を混乱させる並び順

デフォルトの並び順は、アルファベット順または作成日順になっていることが多いですが、どちらも商業的な観点からは合理的ではありません。「Annual Support Fee」が「Platform License」より先に表示されると、購入者は何に対するサポート料金なのかと疑問を抱きます。プロパティ管理では、必ず意図的な並び順を設定してください。

取引プロパティの欠落

「Payment Terms」を参照するテンプレートを使用している場合、ほとんどの取引でそのフィールドが入力されていないと、条件が記載されるべき箇所が空白になった見積書が生成されます。取引パイプラインでそのフィールドを必須項目にするか、デフォルト値を設定するか、またはテンプレートから削除してください。

PDFのフォーマットの問題

Google DocsからPDFへの変換は概ね忠実ですが、一部にずれが生じることがあります。余白が非常に狭い表ではテキストが切れる場合があります。背景色がわずかに異なる色合いで描画されることもあります。プレビューに頼るのではなく、必ず実際のPDF出力をダウンロードして開いて確認してください。購入者が受け取るのはPDFであり、Docではありません。

カスタム価格での未確認送信

担当者が40%の割引を適用して商談を成立させようとし、見積書を生成してレビューなしに送信してしまうことがあります。請求書がレートカードと一致しないことが判明したとき、初めて経理部門が気づく事態となります。一定の閾値を超える割引を許可する場合、レビューは任意ではありません。これは担当者の自律性に任せるのではなく、ワークフローに組み込んでください。

よくある質問

取引ステージから見積書をトリガーできますか？

はい。テンプレートが安定したら、HubSpot ワークフローと Portant アクションを組み合わせてご利用ください。登録条件を価格が確定した取引ステージに設定し、データが反映されるまでの短い遅延を追加してから、アクションを見積書ワークフローに向けてください。順序設定のアイデアについては、 ドキュメントワークフローの取引ステージ をご参照ください。

CPQツールを使用している場合はどうなりますか？

CPQが HubSpot の取引明細に価格を書き戻す仕組みになっている場合、Portant は同様の方法でそれらの値を差し込むことができます。CPQが入力するフィールドをトークンにマッピングしてください。数値がCPQ内にのみ存在し、HubSpotに同期されない場合は、差し込みワークフローで使用できるよう、事前にそのデータを取引に反映させる必要があります。原則はシンプルです。Portant は HubSpot を読み取ります。データが HubSpot にあれば、正常に機能します。

合計金額の誤りをデバッグするにはどうすればよいですか？

HubSpot 上の取引の明細と、Portant の差し込みプレビューを比較してください。十中八九、原因は次の3つのいずれかです。更新されていない古いプロパティ値、ソース設定で選択されていないカスタム明細フィールド、または予期しない並び順です。頻度は低いですが、取引金額が誰かに手動で編集されたため、明細の合計と一致しないケースもあります。HubSpot 上で修正してから、ワークフローを再実行してください。

Portant はマルチ通貨に対応していますか？

Portant は、HubSpot の取引および明細に保存されている値をそのまま差し込みます。HubSpot ポータルでマルチ通貨を使用しており、取引が EUR の場合、明細の価格は EUR となり、Portant はそれらの EUR の値を出力します。購入者が何の通貨を見ているか分かるよう、テンプレートに通貨コードまたは記号を含めてください。Portant は通貨間の換算は行いません。それは HubSpot の役割です。

同じドキュメントに利用規約を含めることはできますか？

はい。テンプレートの価格表の下に、標準の利用規約を記載した静的テキストセクションを追加してください。このテキストはトークン化されていないため、取引ごとに変わることはありません。異なる条件が必要な取引（エンタープライズと SMB、または地域の違いなど）については、テンプレートのバリアントを別途管理するか、取引プロパティに基づいて適切な条件を表示する条件付きセクションを使用してください。

価格交渉の途中で価格が変わった場合、見積書のバージョン管理はどうすればよいですか？

ワークフローを実行するたびに、Portant は新しい出力を生成します。以前の出力を上書きすることはありません。そのため、購入者が価格の見直しを求めた場合は、HubSpot の取引の明細を更新してから、見積書ワークフローを再実行してください。これにより、元の見積書と修正後の見積書の2つの出力が作成されます。どちらも Portant の出力履歴に記録され、HubSpot のレコードに添付されます。現在のバージョンが誰でも判別できるよう、ファイル名に日付またはバージョン番号を付けてください。