SaaS営業代行への機能変更の伝え方｜回答集・資料・説明を更新するチェックリスト

営業担当が知っている情報と、顧客へ約束してよい情報は同じではありません。製品の内部検討、限定提供、正式提供を同じフォルダーへ置くだけでは、対応範囲を取り違えます。機能ごとに案内区分を付け、商談で使える説明を承認します。

価格や契約条件も製品の変更情報と連動します。旧契約と新規契約で条件が異なる場合は、誰に適用されるかを明記し、全顧客に一律の説明をしないようにします。

以下は架空の「データ出力機能の変更」を使った記入例です。リベラルハーツや特定のSaaSの仕様を示すものではありません。

通知文の冒頭には、今回どの会話が変わるのかを短く書きます。「資料を差し替えました」だけでなく、「出力範囲を聞かれた場合は、権限とプランを確認して回答してください」のように行動へ落とします。

最新の回答集を一か所に置き、各回答に質問ID、承認済み回答、適用条件、根拠資料、承認日、責任者を持たせます。顧客からの質問を追加する欄と、対外回答として使える欄は分けます。担当者が自由に書き足した回答を、そのまま正式情報にしないためです。

HubSpotの公式資料では、営業用プレイブックの公開・非公開や版の履歴確認が案内されています。利用できる機能は契約や権限によります。専用ツールを使わなくても、共有文書の版・承認者・適用日を管理し、未承認案と区別する運用から始められます。

• 稼働中の担当者が見るURLを固定する
• ダウンロードした資料にも版と更新日を付ける
• メールひな形・CRM内の定型文など、複製先を一覧にする
• 旧版を参照用に保存する場合は、使用停止を明示する
• 外注先が複数なら、各責任者の反映状況を分けて確認する

共有リンクの本文だけを更新しても、予約済みメールの文面や添付PDFは自動で変わらない場合があります。変更の重要度に応じて、送信前の内容も確認してください。

案内を開いたことと、顧客へ正確に説明できることは別です。短い場面設定を用意し、実働する担当者に回答してもらいます。以下も仮の機能変更に対するテスト例です。

間違いがあれば本人の記憶力だけを原因にせず、回答集が探しにくい、条件が別資料に散らばっている、社内の承認が曖昧といった運用も見直します。修正後は同じ質問だけを暗記させず、条件を変えた別の場面で確認します。

1. 変更した機能や条件が検討理由になっている案件を抽出します。
2. 過去に何を説明したかを、メール・商談記録・使用資料の版で確認します。
3. 再説明が必要な案件と、影響しない案件を分けます。
4. 社内承認した内容で顧客へ案内し、回答と次の行動を記録します。
5. 旧版の使用停止、資料の差し替え、担当者の理解確認を責任者が確認します。

誤った確約があった場合は、担当者だけで取り繕わず責任者へ報告します。「新しい仕様になりました」と曖昧に済ませず、以前の説明のどこを訂正するか、顧客の判断へどう影響するかを整理してください。

完了記録には変更ID、対象担当者、更新先、確認日、未完了事項を残します。通常の軽微な変更と、価格・提供可否に関わる重要な変更で確認の深さを変えると、毎回すべてを作り直す負担も抑えられます。

この手順は営業代行の比較ではなく、契約後の情報更新を扱うものです。依頼範囲や役割分担を整理したい場合はSaaS向けインサイドセールス代行の選び方もご覧ください。