サービスを改善するには変化が必要です。一方、使っている顧客は「前と同じように使えること」を前提に業務を組んでいます。新しい機能が増えても、既存の作業が予告なく変われば混乱が生じます。
そのためBtoBサービスの信頼を考えるときは、「ブランドに一貫性を持たせる」という一般論から一歩進める必要があります。何を守り、何を変え、誰に、いつ、どの範囲で知らせ、問題が起きたらどう戻すかを、顧客の業務と契約に合わせて明確にすることです。
一貫性とは「機能を永遠に変えない」ことではない
変更前と後で画面や運用がまったく同じである必要はありません。改善によって使い勝手や安全性が高まることもあります。ただし、顧客にとって大切な「契約どおりに利用できる」「問い合わせが届く」「変更理由が分かる」「必要な準備ができる」といった期待を守る必要があります。
GOV.UKのサービス基準（チャネルを通じた体験の一貫性）は、Webだけでなく電話・対面などの接点で情報や説明が食い違わないようにすること、現場の担当者へ変更点を伝えることを重視しています。これは政府サービス向けの基準であり、BtoB企業へ直接の法的義務として適用するものではありません。
守るべき核と、変えてよい施策を分ける
| 項目 | 守ることの例 | 変更を検討できることの例 |
|---|---|---|
| 約束・契約 | 提供範囲、品質条件、課金・解約条件 | 更新可能な機能の提供方法 |
| 顧客の判断 | 正確な仕様、導入条件、変更日、制約 | 説明の順序、文書・画面の表現 |
| サポート | 連絡先、緊急時の案内、エスカレーション | 問い合わせ受付画面や担当体制 |
| マーケティング | 根拠のある価値提案、実績と推測の区別 | 広告媒体、記事形式、配信方法 |
| 内部運用 | 責任者、承認と変更履歴、安全の確認 | 業務システムや制作の手順 |
この表は当サイトによる実務の分類であり、すべての変更が許されるという意味ではありません。契約・法令・顧客の個別事情に応じて、変更の可否や手続きは異なります。
仕様変更で顧客が知りたいことを先に整理する
例えばAPIのバージョンを変更する、管理画面の設定項目を移動する、料金の単位を変えるといった変更では、変更した事実だけでは足りません。顧客が自社で対応すべき作業と期限を把握できるようにします。
- 対象：どのプラン、機能、顧客・環境が影響を受けるか。
- 変化：何が追加・変更・終了し、従来の方法はどうなるか。
- 時期：変更日、切り替え期限、段階導入や例外の扱い。
- 必要な作業：顧客側で設定や教育、コード変更などが必要か。
- 回避・代替：移行できない場合の選択肢、復旧・ロールバック可否。
- 支援：問い合わせ先、公式の仕様・手順、後日の更新場所。
全員へ同じメールを送ることが最善とは限りません。影響の有無や担当者の権限に合わせて知らせる必要があります。技術的な移行案内は運用担当者、契約条件は購買・法務担当者へと、伝える情報を分ける場合もあります。
障害時には「安心させる文章」より現状と次の連絡
BtoBサービスの障害で「間もなく完全復旧します」と根拠なく言うと、顧客はその情報をもとに業務判断を誤るかもしれません。原因が不明なら不明と伝え、確実に分かる影響範囲と調査状況を分けます。
AtlassianのStatuspage向け障害連絡チュートリアルは、Investigating（調査中）、Identified（問題特定）、Monitoring（復旧後の監視）、Resolved（解決）などの段階を分け、連絡テンプレートに次回更新予定を入れる設計を紹介しています。
ここで参考にできるのは、次の更新を伝えることと、復旧時刻を約束することは違う、という点です。原因がまだ分からないときでも、次に情報を出す予定を明らかにできます。
顧客向け変更・障害通知の記入例
| 記載欄 | 仕様変更の場合 | 障害発生の場合 |
|---|---|---|
| 何が起きる／起きたか | 設定画面の移動、旧方式の終了予定 | 一部の利用者で認証できない報告 |
| 影響範囲 | 対象プランと旧設定を使う環境 | 影響を確認できた機能と未確認範囲 |
| 必要な対応 | 指定日までに設定を確認 | 代替手段があれば正確に案内 |
| 今の確定情報 | 変更仕様、正式な確認先 | 調査結果、復旧可否、原因の確度 |
| 次の連絡 | 変更時刻前の再案内など | 次回の状況更新予定 |
| 連絡先 | サポート窓口、手順書 | 障害の状況ページ、緊急窓口 |
これは架空の記入例であり、実際の事故・変更の報告ではありません。深刻なセキュリティ事故や法令上の通知が必要な事案では、通常の告知テンプレートより専門の対応手順を優先してください。
営業・マーケティング・CSの間で「説明の正本」をそろえる
新仕様が公開されても、営業資料には旧機能、ヘルプには新機能、マーケティングのWebページには旧料金が残っている場合、どの説明が正しいか分からなくなります。
GOV.UKの政府サービス設計の入門資料は、利用者が最初の接点から完了まで一つのサービスとして使えることや、異なる接点でデータ・表現を整合させる重要性を説明しています。
これをBtoBの実務へ応用するなら、更新対象をWeb、営業資料、価格表、契約前の案内、FAQ、社内の問い合わせ対応文面に分け、責任者と更新日を記録することが考えられます。
- 変更の正本：製品責任者が承認した仕様、価格、適用条件、切り替え時期。
- 影響する資料：Web、契約書、提案資料、営業メール、FAQ、サポートナレッジ。
- 担当者：事実の承認、文章の更新、公開、顧客通知の責任を分ける。
- 完了の証拠：実際の公開ページや顧客向け通知を確認する。
- 次の監査：変化しやすい数値や仕様の再確認時期を設定する。
AIの利用で一貫性が高まるとは限らない
生成AIを使えば、仕様変更の長い説明を短く要約し、別の読者向けに言い換えることはできます。しかし、元の仕様の版が間違っていれば、その誤りを複数媒体へ広げるおそれがあります。
まず、確定した資料と承認日を特定し、AIが追加した断定や省略した条件を確認します。顧客の機密情報や契約データをAIへ渡す前には、利用する環境・権限・契約を確認する必要があります。
変更後、信頼を測るのは「好評だったか」だけではない
変更についての評価は、メール開封やSNS上の反応だけでは分かりません。利用者が必要な準備を実施できたか、サポートへの質問がどのように変わったか、困っている顧客を把握できているかを確認します。
- 対象顧客に、必要なタイミングで変更内容が届いたか。
- 案内後も残った質問や、作業が進まない原因は何か。
- 旧資料・旧料金・旧仕様が検索結果や営業資料に残っていないか。
- 障害時の説明と実際の調査状況・復旧記録が整合しているか。
- 問題があった場合に、どの担当が是正し再発防止まで確認したか。
これらは本記事の評価項目の例であり、特定の施策が顧客の継続率や信頼度を改善したと実証するものではありません。
関連資料と記事
- GOV.UK：異なる接点を通した一貫したサービス — 現場とオンラインの変更情報をつなぐ公的指針。
- GOV.UK：サービス設計の全体像 — 利用者の一連の体験と情報の一貫性。
- Atlassian：障害連絡テンプレートの作り方 — 状況・影響・次回更新の示し方。
- BtoBのクレーム対応と再発防止 — 苦情を受けた後の記録と改善。
- ひとりマーケターの役割分担・RACI — 部門間で更新責任を明確にする。
- BtoBの価格設計 — 価格改定の前提となる価値・原価・条件。
公的サービスの指針やAtlassianの製品チュートリアルを参考にしていますが、それらがBtoB企業のあらゆる変更管理を義務づける標準という意味ではありません。契約上の通知義務、個人情報やセキュリティの対応、業界固有の規制は別途確認が必要です。
信頼に必要なのは、絶対に変わらないことではありません。変えるべき理由を確かめ、顧客が判断できる情報を残し、問題が起きたときに隠さず対応すること。その積み重ねを、ブランドの言葉だけでなくサービスの運営として示すことが大切です。