Customer 360 (Account 360)

この言葉は単純に聞こえますが、実装は要求が厳しいものです。本物のCustomer 360は、アカウントの身元（会社、連絡先、プラン）、収益シグナル（MRR、サブスクリプションの状態、請求履歴）、プロダクトへの関与（機能の利用、セッションデータ、直近の活動）、サポート履歴（未対応・対応済みのチケット、感情）、提出されたフィードバック、そのアカウントに紐づく進行中の作業項目をすべて1つにまとめます。これらの側面がすべて結びついていなければ、手に入るのは完全な全体像ではなく、いくつかの半端なビューにすぎません。

実用的な価値はスピードと確信にあります。更新の電話に対応するカスタマーサクセスマネージャー、機能リクエストをトリアージするプロダクトマネージャー、苦情をデバッグするエンジニア——いずれも同じアカウントの異なる断面を必要としています。本物の360ビューであれば、誰も5つのタブを切り替えたり、同僚にレポートを頼んだりする必要がありません。

ほとんどのチームは、CSVを書き出したり、脆いオートメーションの連鎖を組んだり、アカウントの営業側しか見ていないCRMに頼ったりして、Customer 360を近似的に作ろうとします。データが2つ以上のシステムに存在するようになった瞬間、結合は崩れます——そして現代のプロダクトチームは通常、十数個のシステムに触れています。Stripeは収益を保持します。GitHubとLinearは作業を保持します。IntercomやZendeskはサポートを保持します。PostHogやAmplitudeは利用状況を保持します。これらのどれも「Acme Corpについてのすべてを1つの画面で見せてくれ」という問いに答えるようには設計されていません。

プロダクトのためのオペレーティングシステムは異なるアプローチを取ります。ツール間でデータのコピーを同期させる代わりに、コネクタが書き込む共有データ基盤を維持します。AIOProductOSはこれをAccount 360ビューで実現しています。顧客レコードを、その請求サブスクリプション、そのアカウントに紐づけられた提出済みフィードバック、予定されているミーティング、そのアカウントに関連付けられたインサイトと結びつけます——すべて同じ基盤データから取得します。行動（利用イベント）、作業（GitHub、Linear）、会話（Intercom、Zendesk）のセクションもこのビューに存在し、各コネクタが接続されるにつれて中身が入ります。接続されるまでは、正直な空の状態が表示されます。結合が1か所に存在するため、ビューは手作業での照合なしに最新の状態を保ちます。

有用なテストがあります。任意の有料顧客を1つ選び、次の3つの質問に、1つの画面から離れずに答えるのにどれだけ時間がかかるかを計ってみてください——現在のMRRはいくらか、最後に開いたサポート課題は何か、提出したプロダクト機能リクエストは何か。答えるのにツールを切り替えたり誰かに聞いたりする必要があるなら、あなたはまだCustomer 360を持っていません。あなたが持っているのは、たまたま顧客データを含んでいるだけのデータサイロです。

目標はダッシュボードそれ自体ではありません。その顧客に影響する意思決定——優先順位付けの会議、更新の会話、バグのトリアージ——を今まさに行おうとしている人に、顧客のコンテキストを即座に利用可能にすることです。360ビューの本当のリターンは、その意思決定の質の中にあります。