BtoBサービスの受注後90日をどう設計するか|オンボーディング・不安解消・継続評価

受注が決まった瞬間、営業は次の案件へ向かい、マーケティングも新しいリード獲得に戻る。しかし、顧客側ではそこから新しい問題が始まります。担当者への引き継ぎ、社内説明、システム設定、利用者への周知、初期成果の確認。導入に必要なことが抜け落ちると、契約直後の期待と実際の体験の間に溝が生じます。

この記事では、旧記事の「受注直後の不安を解消する」という視点を引き継ぎながら、BtoBサービスの受注後90日を、責任者・顧客の目的・確認指標から設計します。90日は説明用の区切りであり、すべてのサービスに共通の導入期間や成果を保証するものではありません。

購入直後の「認知的不協和」だけで説明しない

契約後に顧客が「この選択でよかっただろうか」と考えることはあります。しかし、その理由は必ずしも心理学の「認知的不協和」だけとは限りません。契約内容に含まれる作業が不明、社内の利用者が参加できない、導入時期がずれた、期待した機能に制約がある、など具体的な問題がある場合もあります。

したがって「安心させるメール」を送りさえすれば問題が解消するとは考えません。最初に必要なのは、何が約束され、何がまだ実現していないかを両者で確認することです。

営業・導入担当・顧客の3者で、約束を引き継ぐ

契約直後には、営業資料に書かれていること、見積・契約に明記したこと、口頭で説明したこと、まだ未確認のことが混ざりがちです。ここを一つの「引き継ぎメモ」にまとめ、顧客が認識している成果とずれていないかを確かめます。

  • 導入目的:顧客は何を改善したくて契約したのか。成果の定義は何か。
  • 提供範囲:契約で含まれる業務、顧客が担う作業、含まれない作業。
  • 関係者:決裁者、実務責任者、利用者、支援担当者と連絡先。
  • 前提・リスク:システム権限、連携先、利用規約、データ、組織的な依存関係。
  • 未解決の論点:契約前の約束を確認する必要がある箇所、期限と担当。

この確認を省略して一方的に「順調です」と案内すると、顧客が困っていることを拾えません。必要なら契約時の資料へ戻り、双方が納得できる範囲を確かめます。

0〜90日の例:日数より「確認できた状態」を重視する

時期の例顧客が判断できること企業側が記録すること
契約〜開始何を、誰と、どんな順序で始めるか契約条件・担当・初期課題・開始条件
初期設定使い始めるための前提が整ったか設定・権限・支援依頼・残る障害
利用開始利用者が目的の作業を実際に進められるか初回利用・問い合わせ・つまずきと対処
定着の確認当初の目的へ進んでいるか成果の定義に沿った事実、顧客の声、未解決事項

これは特定のクラウドサービス企業を想定した架空の例です。高度な業務システムでは3か月以上かかることもあれば、数日で価値が生まれる製品もあります。期間を先に固定して、その間にすべて完了したことにしないでください。

確認する指標は「利用ログ」だけでは足りない

たとえば利用頻度が高くても、限られた少数の担当者が無理をして使っているだけかもしれません。逆に利用頻度が低くても、四半期ごとに使うサービスなら想定どおりかもしれません。顧客の業務の周期や成功条件を理解せず、ログの多寡だけで健全性を決めることはできません。

HubSpotは、カスタマーサクセス用の健全性スコア機能で、顧客レコードの属性や行動データに基づく評価の仕組みを提供しています。ただしスコアは、選んだ条件によって計算される指標です。顧客の満足や継続意思を直接読める装置ではありません。

  • 導入の完了:利用開始に必要な設定・説明・顧客側の確認が終わったか。
  • 利用上の障害:対応できていない問い合わせや権限の問題がないか。
  • 期待との一致:契約時に定義した成功条件に対して、何が実現し何が残るか。
  • 顧客からの意見:担当者や利用者の声を直接確認できるか。
  • 継続を考える条件:コスト、運用負担、代替案、社内方針など変化した前提はないか。

「ヘルススコア」を作るときの注意

HubSpotの公式ヘルススコアカード説明では、面談実施やNPSなどの肯定的なシグナル、未解決のサポートチケットなどのリスク指標を組み合わせられると説明しています。これは製品機能の例であり、同じ重みや閾値がすべてのBtoB企業に適切なわけではありません。

スコアが上がるかどうかだけに注目すると、顧客との会話を増やすことが目的化したり、重要なトラブルが平均点の中に埋もれたりすることがあります。契約上・安全上の重大問題は単純なスコアと別に扱い、顧客からの明確な意思表示を優先します。

LTVは「満足した気持ち」そのものではない

顧客生涯価値(LTV)は、企業が顧客との関係から得る経済的な価値をどう捉えるかという指標で、売上ベース・粗利ベース、期間、獲得・サポート費用の扱いによって定義が異なります。

継続率、更新金額、追加契約、利用コストなどを把握できなければ、LTVが改善したと数値で断定することはできません。逆にサポート費用を減らすことだけを優先すると、顧客の体験や安全性が損なわれる可能性があります。

経営への説明では、契約条件と計測方法を明示し、「顧客が望む成果を得られているか」と「事業の収益性」をそれぞれ確認します。

不安への対応には、説明より解決が必要なこともある

契約直後の不安を、きれいな歓迎メールだけで消すことはできません。ユーザーが作業でつまずいている場合は、手順の説明、仕様の改善、サポート体制、担当者間の調整など、問題そのものへの対応が必要です。

英国政府のサービス全体の満足度を測る指針でも、オンラインの一つの作業が終わることと、利用者の体験全体が終わることを区別しています。これは公共サービスの設計資料ですが、購入後の体験を「契約手続き完了」で終わらせないという点で参考になります。

少人数でも始められるレビューの仕組み

  • 契約直後の引き継ぎメモを一枚で共有し、未確認事項を明記する。
  • 導入の節目で、顧客に「当初望んだことに向け、どこが進み、どこが困っているか」を尋ねる。
  • 問い合わせと問題の原因を、営業・導入・開発・サポート間で確認できる形に整理する。
  • 利用状況と顧客の声が食い違う場合、どちらかを無視せず背景を調べる。
  • 更新時期の直前だけでなく、必要な頻度で課題と成果を確認する。

この運用はすべての業種へそのまま当てはまる規格ではありません。人員や導入の複雑さに合わせ、誰も使わない大量の報告項目を増やさないことも重要です。

関連資料と記事

ここで示した日程表とチェック項目は当サイトによる実務上の提案です。各顧客の契約、製品、支援範囲によって適切な運用は異なります。実際の成果やLTV改善を示すものではありません。

BtoBの受注後に重要なのは、不安が消えたように見せることではなく、約束したことが実現しているかを顧客と一緒に確かめ、問題があれば対応することです。導入後の時間を「販売の後始末」ではなく、価値を届ける工程として設計することから、長く続く関係は始まります。

ほかの記事を探す

記事の訂正・出典情報は、お問い合わせから該当記事のURLと根拠資料をお知らせください。