Agentic CRMで実現する顧客体験設計の進め方｜設計と実行を分けて考える

顧客体験の設計に取り組む中で、ジャーニーマップやペルソナは作れても、それが実際の顧客対応に反映されないまま終わってしまう、という手応えのなさを感じている方は多いのではないでしょうか。顧客体験設計とは、顧客が製品やサービスに触れる一連の接点を洗い出し、どの場面で何を届けるかを先に決めておく取り組みです。結論から言うと、顧客体験設計が成果につながらない最大の原因は、設計の質の問題ではありません。設計した体験を一人ひとりの顧客に実行し続けられないことにあります。設計フェーズと実行フェーズを分けて考えると、この問題の在りかがはっきりします。

本記事では、この設計の考え方をAgentic CRMの枠組みにもとづいて整理します。

そこで本記事では、顧客体験設計を「設計フェーズ」と「実行フェーズ」に分け、実行フェーズをAgentic CRMがどのように担うのかを、BtoBの顧客接点別の活用場面や実装ステップまで含めて解説します。

顧客体験設計は、一般には次の順で進めます。まず顧客の行動を時系列に並べてジャーニーマップを作り、次に接点ごとの課題と改善案を洗い出します。そのうえで担当部門を割り当て、最後に満足度やNPSで効果を確かめる、という流れです。この記事は、この流れの4番目まで作っても実行されずに止まるという問題から入り、設計した体験を誰が動かし続けるのかという実行フェーズの側を扱います。

なぜ広がらない？顧客体験設計が実行で止まる理由

本記事では、勤怠管理のクラウドサービスを提供する中堅のBtoB SaaS企業（従業員約250名・営業とサポートでそれぞれ別のCRMを使っている・取引社数の増加で顧客対応が追いつかない課題を抱える）が、顧客体験設計に取り組んだケースを例に、解説を進めます。多くの企業がジャーニーマップまでは作れても、その先の実行でつまずきます。そこでここでは、顧客体験設計が設計まではできても実行でスケールしない理由を、3つに分けて整理します。

顧客体験設計がスケールしないのは、設計の出来のせいではありません。設計した体験を顧客一人ひとりに実行し続ける仕組みが欠けているからです。

理由①ジャーニーマップは作れるが顧客ごとの実行に落とせない

1つ目の理由は、ジャーニーマップは作れても、それを顧客ごとの実行に落とせないことです。なぜなら、ジャーニーマップは平均的な顧客像を前提に描かれる一方、実際の顧客は一社ずつ状況もタイミングも異なるからです。

マップ上では「この段階でこの情報を届ける」と決められても、実際にどの顧客が今どの段階にいるのかを一件ずつ把握するのは、人の手では追いつきません。設計は理想の流れを描き、実行は個別の現実に一件ずつ対応する作業になります。

たとえば、この勤怠管理SaaS企業では、丁寧なジャーニーマップを作ったものの、実際には全顧客へ同じタイミングで同じメールを送る運用になっていました。設計した体験と、現場で届いている体験のあいだに、大きな開きが生まれていたのです。

このように、ジャーニーマップを顧客ごとの実行に落とせないことが、最初の理由になります。

理由②顧客データが複数システムに分散して個別判断の材料がない

2つ目の理由は、顧客データが複数のシステムに分散していて、個別の判断材料がそろわないことです。なぜなら、顧客ごとに最適な対応を選ぶには、その顧客の行動や状況を一元的に把握する必要があるからです。

マーケティングツールにはWebの行動履歴が、営業システムには商談の記録が、サポートツールには問い合わせ履歴が、それぞれ別々に蓄積されています。データが分かれていると、一人の顧客の全体像が見えず、個別の判断ができません。部門をまたいでデータが分断される構造はRevOpsの記事でも扱っています。

たとえば、この勤怠管理SaaS企業では、ある顧客が資料を何度もダウンロードしていました。その情報が営業に共有されず、フォローのタイミングを逃しています。判断に必要な材料が、システムをまたいで散らばっていたのです。

このように、顧客データが分散して個別判断の材料がそろわないことが、2つ目の理由になります。

理由③アカウント数が増えるほど担当者の処理能力が追いつかない

3つ目の理由は、担当するアカウント数が増えるほど、担当者の処理能力が追いつかなくなることです。なぜなら、一件ずつ状況を確認して個別に対応するやり方は、顧客数に比例して工数が増えていくからです。

顧客が数十社のうちは、担当者が一社ずつ丁寧に対応できます。しかし、数百社に増えると、全社の状況を把握して個別に動くのは物理的に難しくなります。人を増やして対応しようにも、採用と育成が追いつきません。

たとえば、この勤怠管理SaaS企業では、取引社数が200社を超えたあたりから、CS担当者が全顧客の状況を追いきれなくなりました。手厚く対応できる顧客と、放置される顧客に分かれてしまったのです。

このように、アカウント数の増加に担当者の処理能力が追いつかないことが、3つ目の理由になります。

顧客体験設計の「設計フェーズ」と「実行フェーズ」

3つの理由に共通するのは、設計と実行がひとつながりのまま扱われていることです。ここを2つのフェーズに分けると、どこをAIに任せられるのかが見えてきます。Agentic CRMとは、AIエージェントがCRM上で自律的に判断・行動し、顧客対応を実行する仕組みのことです。そこでここでは、顧客体験設計を設計フェーズと実行フェーズに分けて整理します。

顧客体験設計は、方針を決める設計フェーズと、それを全顧客へ届ける実行フェーズに分かれ、スケールを阻むのは常に実行フェーズです。

下の表で、設計フェーズと実行フェーズの担い手と内容を整理します。

設計フェーズ：ジャーニーマップ・ペルソナ・接点方針の定義は人が担う

設計フェーズは、どんな顧客へ何を届けるかという方針を決める工程で、ここは人が担います。段階ごとの区切り方も、この工程で決めます。なぜなら、事業の狙いや顧客理解に基づいて体験の方針を描くことは、人の判断が欠かせない領域だからです。

ジャーニーマップの作成、ペルソナの定義、接点ごとの方針づくりは、顧客への理解と戦略から生まれます。ここはAIに丸ごと委ねる部分ではありません。人が事業の意図を込めて設計する領域です。

たとえば、この勤怠管理SaaS企業でも、導入直後から更新期までの段階ごとに、どんな情報を届けるべきかという方針を決めました。議論に加わったのは、マーケティングと営業とCSの3部門です。体験の骨格を描く設計フェーズは、人の役割として残ります。

このように、方針を定義する設計フェーズは、これまでどおり人が担います。

実行フェーズ：個別配信・タイミング判断・接点対応はAgentic CRMが担う

実行フェーズは、設計した方針を一人ひとりの顧客に届ける工程で、ここをAgentic CRMが担います。なぜなら、個別の配信やタイミングの判断、接点ごとの対応は、顧客数が増えるほど人手では回らなくなるからです。

どの顧客が今どの段階にいて、次に何を届けるべきかを一件ずつ判断し、実行します。この繰り返しこそ、担当者の処理能力を超えていく部分です。ここをAIエージェントが自律的に引き受けます。

たとえば、この勤怠管理SaaS企業では、顧客ごとの利用状況に応じて、次に届けるコンテンツやタイミングをAgentic CRMが判断して配信するようにしました。担当者が一件ずつ手を動かしていた実行を、AIが引き受けたのです。

このように、個別の実行を担う実行フェーズは、Agentic CRMの役割になります。

この分業が成立した瞬間に顧客体験設計は初めてスケールする

設計フェーズを人が、実行フェーズをAgentic CRMが担うという分業が成立したとき、顧客体験設計は初めてスケールします。なぜなら、人が描いた方針を、顧客数に関係なく全員へ実行し続けられるようになるからです。

これまでは、良い設計をしても、届けられる顧客の数が担当者の工数で上限に達していました。実行をAIが担えば、設計の質を保ったまま、対象を全顧客へ広げられます。

たとえば、この勤怠管理SaaS企業では、設計した体験を200社を超える全顧客へ同じ水準で届けられるようになりました。一部の顧客だけが手厚く、残りは放置という状態が解消されたのです。

このように、設計と実行の分業が成立した瞬間に、顧客体験設計はスケールします。

顧客体験の実行フェーズを変える3つの仕組み

実行フェーズをAgentic CRMが担うと言っても、具体的に何が変わるのかが気になります。Agentic CRMは、これまで人が一件ずつ処理していた実行を、3つの仕組みで置き換えます。そこでここでは、実行フェーズを変える3つの仕組みを解説します。

Agentic CRMは、全接点データのリアルタイム統合・ステージ変化の自律判断・接点対応の自律実行という3つの仕組みで、実行フェーズをスケールさせます。

仕組み①AIエージェントが全接点のデータを統合して顧客プロファイルをリアルタイム更新する

1つ目の仕組みは、AIエージェントが全接点のデータを統合し、顧客プロファイルをリアルタイムに更新することです。なぜなら、個別の判断を下すには、その顧客の最新の状況が一箇所にそろっている必要があるからです。

Webの行動、商談の進捗、サポートの問い合わせといった接点のデータが、発生した時点でプロファイルに反映されます。担当者が手作業で情報を集めて回る必要がなくなり、判断の材料が常に最新に保たれます。

たとえば、この勤怠管理SaaS企業では、顧客が料金ページを見た行動から過去の問い合わせ履歴までが、ひとつのプロファイルにまとまって更新されるようになりました。これまで営業が探し回っていた情報が、自動でそろうようになったのです。

このように、全接点データを統合してプロファイルをリアルタイム更新することが、最初の仕組みになります。

仕組み②顧客のステージ変化をAIが検知してコンテンツ・タイミング・チャネルを自律判断する

2つ目の仕組みは、顧客のステージ変化をAIが検知し、届けるコンテンツ・タイミング・チャネルを自律的に判断することです。なぜなら、顧客ごとに最適な対応は状況によって変わり、その変化を人がすべて追うのは難しいからです。

検討が進んだ、利用が活発になった、逆に利用が減ったといったステージの変化を、AIがデータから読み取ります。そのうえで、次に何を、いつ、どのチャネルで届けるかを判断します。一人ひとりに合わせる実装は個別化の記事で扱っています。

たとえば、この勤怠管理SaaS企業では、無料トライアルの利用が活発になった顧客をAIが検知し、その段階に合った導入事例を、最適なタイミングでメール配信するようにしました。担当者が気づく前に、次の一手が動くようになったのです。

このように、ステージ変化を検知して対応を自律判断することが、2つ目の仕組みになります。

仕組み③接点ごとの個別対応をAIが自律実行してスケールを維持したまま個別化できる

3つ目の仕組みは、接点ごとの個別対応をAIが自律実行し、スケールを維持したまま個別化できることです。なぜなら、判断だけで終わらず、実際の配信や通知まで自動で実行して初めて、全顧客への個別対応が回るからです。

判断した内容を、AIがそのまま実行に移します。人が最終確認する運用も組めますが、定型的な対応はAIが自ら動くため、顧客数が増えても対応の質が落ちません。

たとえば、この勤怠管理SaaS企業では、ステージに応じたコンテンツ配信や営業への通知を、AIが自律的に実行するようにしました。200社を超えても、一社ずつに合わせた対応を同じ水準で続けられるようになったのです。

このように、個別対応を自律実行してスケールと個別化を両立することが、3つ目の仕組みになります。

接点4選｜BtoBの顧客体験で自律化が効く場面

3つの仕組みが、実際の顧客接点でどう働くのかを見ると、実行フェーズの変化が具体的になります。BtoBでは、接点ごとに実行すべき対応が異なります。そこでここでは、BtoBの顧客接点別に、Agentic CRMの活用場面を4つ紹介します。

Agentic CRMは、Web訪問・商談後フォロー・アップセル・解約兆候という4つの接点で、個別の対応を自律的に実行します。

接点①Webサイト訪問から資料請求までの自律パーソナライズ

1つ目の接点は、Webサイトの訪問から資料請求までの自律的なパーソナライズです。なぜなら、検討の初期段階では、訪問者の関心に合わせて表示や案内を変えることが、次の行動につながるからです。

同じサイトでも、訪問者が見ているページや流入経路によって関心は異なります。その関心に合ったコンテンツや資料を出せれば、資料請求までの距離が縮まります。

たとえば、この勤怠管理SaaS企業では、料金ページを繰り返し見ている訪問者に対して、AIが導入事例と料金の詳しい資料を優先して案内するようにしました。関心の高い訪問者を、資料請求まで自然に導けるようになったのです。

このように、Web訪問から資料請求までの自律パーソナライズが、最初の活用場面になります。

接点②商談後フォローから契約更新までのCSシナリオの自律実行

2つ目の接点は、商談後のフォローから契約更新までを、CSシナリオとして自律実行することです。なぜなら、契約後の体験が更新の可否を左右するにもかかわらず、フォローが担当者の時間の制約で滞りがちだからです。

導入直後のオンボーディング、活用が進んだ段階での提案、更新前の確認といった対応を、あらかじめシナリオとして設計しておきます。そのシナリオを、顧客ごとの進み方に合わせてAIが実行します。買い手側で検討がどう進むかは購買体験の記事で扱っています。

たとえば、この勤怠管理SaaS企業では、導入から更新までのCSシナリオをAgentic CRMが顧客ごとに実行し、活用が滞っている顧客には早めにフォローを入れるようにしました。更新前に慌てて対応する状態から抜け出せたのです。

このように、商談後フォローから契約更新までのCSシナリオの自律実行が、2つ目の活用場面になります。

接点③既存顧客のアップセルタイミングをAIが自律検知する

3つ目の接点は、既存顧客のアップセルのタイミングを、AIが自律的に検知することです。なぜなら、アップセルは顧客の状況が整った瞬間を捉えられるかどうかで、成否が大きく変わるからです。

利用が上限に近づいた、新しい機能をよく使い始めた、従業員数が増えたといった変化は、上位プランや追加機能を提案する好機です。この兆候をAIがデータから見つけ、営業へ知らせます。

たとえば、この勤怠管理SaaS企業では、登録従業員数が契約プランの上限に近づいた顧客をAIが検知し、上位プランの提案を営業へ通知するようにしました。提案の機会を逃さずに捉えられるようになったのです。

このように、アップセルタイミングの自律検知が、3つ目の活用場面になります。

接点④解約兆候をAIが検知してプロアクティブフォローを自律実行する

4つ目の接点は、解約の兆候をAIが検知し、先回りのフォローを自律実行することです。なぜなら、解約は兆候が表れてから動くほど挽回しやすく、気づいたときには手遅れになりやすいからです。

ログイン頻度が落ちた、主要機能を使わなくなった、問い合わせが増えたといった変化は、解約の兆候です。この兆候をAIが早期に捉え、フォローの連絡や担当者への通知を自動で行います。

たとえば、この勤怠管理SaaS企業では、利用頻度が下がった顧客をAIが検知するようにしました。活用を促す案内を自動で送り、あわせてCS担当者へアラートを出します。解約が表面化する前に手を打てるようになったのです。

このように、解約兆候の検知とプロアクティブフォローの自律実行が、4つ目の活用場面になります。以上が、BtoBの顧客接点別に見たAgentic CRMの4つの活用場面でした。

顧客体験の実行を動かすデータ基盤

接点別の活用場面は、どれも顧客データが整っていることを前提にしています。実行フェーズをAIが動かすには、そのためのデータ基盤が欠かせません。そこでここでは、実行フェーズを動かすデータ基盤を、3つの観点から整理します。

実行フェーズを動かすデータ基盤は、部門横断のデータ統合・AIが判断できる基準の定義・法令に対応した収集設計という3つで成り立ちます。

基盤①マーケ・営業・CSのデータを同一CRM上に統合する

1つ目の基盤は、マーケティング・営業・CSのデータを、同一のCRM上に統合することです。なぜなら、顧客ごとの判断には、部門をまたいだ行動や状況を一元的に参照できる状態が前提になるからです。

Webの行動履歴、商談の記録、サポートの問い合わせが別々のツールに分かれていると、AIは一人の顧客の全体像を参照できません。同じCRM上にデータを集約して初めて、個別の判断が可能になります。統合の範囲が広いほど、AIはより多くの文脈を踏まえて対応を選べます。

たとえば、この勤怠管理SaaS企業では、これまで別々のツールにあったマーケ・営業・CSのデータを、一つのCRMへ集約するところから着手しました。部門ごとに分かれていた顧客情報が、一つのプロファイルにまとまったのです。

このように、部門横断のデータを同一CRM上に統合することが、最初の基盤になります。

基盤②AIが判断できる顧客ステージと行動トリガーの基準を定義する

2つ目の基盤は、AIが判断できるように、顧客ステージと行動トリガーの基準を定義することです。なぜなら、AIが自律的に動くには、どんな状態を「どのステージ」とみなし、何を「行動のきっかけ」とするかの基準が要るからです。

「トライアル中」「活用期」「更新前」といったステージの区切りや、「料金ページを3回見た」「主要機能の利用が止まった」といったトリガーを、あらかじめ言葉と数値で定義します。この基準があるほど、AIの判断は安定します。判断基準を機械へ渡す考え方の全体像はエージェンティックAIの記事で扱っています。基準が曖昧なままでは、同じ状況でも判断がぶれてしまいます。

たとえば、この勤怠管理SaaS企業では、利用状況をもとに顧客ステージを定義しました。どの行動をアップセルや解約のトリガーとみなすかは、マーケ・営業・CSで話し合って決めています。AIが迷わず判断できる基準を、人が用意したのです。

このように、AIが判断できるステージとトリガーの基準を定義することが、2つ目の基盤になります。

基盤③個人情報保護法・GDPRに対応したデータ収集・利用設計をする

3つ目の基盤は、個人情報保護法やGDPRに対応した、データの収集・利用設計をすることです。GDPR（EU一般データ保護規則）とは、EU圏における個人データの取り扱いを定める規則のことです。なぜこれが基盤になるのかというと、顧客データを扱う以上、法令に沿った収集と利用が前提にならないと、運用を続けられないからです。

どのデータを、どの同意のもとで集め、何に使うのかを、あらかじめ設計しておく必要があります。ここが曖昧なままでは、後から利用範囲の見直しを迫られます。自社で構築するので設計レビュー・アドバイザリーだけ頼みたい場合も、この扱いの設計は外部の目を入れる価値があります。

たとえば、この勤怠管理SaaS企業では、データの収集項目と利用目的を整理しました。同意の取得と管理の仕組みを設計してから、AIの活用を進めています。法令への対応を先に固めたことで、安心して運用を広げられたのです。

このように、法令に対応したデータの収集・利用設計をすることが、3つ目の基盤になります。

どう始める？顧客体験設計を実装する3ステップ

データ基盤の要件がわかったところで、実際にどう実装するのかを見ていきましょう。Agentic CRMは、顧客データの統合基盤と、その上で動くAIエージェントを組み合わせて構築します。AIエージェントとは、決めた基準に沿って自ら判断し、配信や通知まで実行する仕組みのことです。そこでここでは、顧客体験設計を実装する3つのステップを解説します。

実装は、顧客プロファイルを統合し、AIの判断基準を設計し、ステージ変化から配信・通知までを動かす、という3ステップで進みます。

ステップ①複数システムに分散した顧客データをCDPで統合して顧客プロファイルを一元化する

1つ目のステップは、統合基盤に各システムを接続し、顧客プロファイルを統合することです。統合基盤とは、社内に分散したデータを一つに束ね、顧客ごとのプロファイルとしてまとめる仕組みのことです。なぜ最初にこれを行うのかというと、統合されたプロファイルが、その後のすべての判断の前提になるからです。

営業・サポート・マーケティングのデータを統合基盤へ接続し、一人の顧客の情報を一つのプロファイルにまとめます。ここがそろわなければ、AIは個別の判断を下せません。小さく始めたい場合は、統合の範囲を1つの部門に絞るところから始めます。

たとえば、この勤怠管理SaaS企業では、まず統合基盤に各システムを接続し、顧客ごとのプロファイルを統合しました。バラバラだった顧客情報が、AIの参照できる形に整ったのです。

このように、統合基盤でプロファイルをまとめることが、実装の最初のステップになります。

ステップ②AIが判断できる顧客ステージとアクション基準を設計する

2つ目のステップは、AIが判断できるように、顧客ステージとアクション基準を設計することです。なぜなら、統合したプロファイルがあっても、どの状態でどう動くかの基準がなければ、AIは自律的に判断できないからです。

顧客のステージ区分と、それぞれの段階で取るべきアクションの基準を設計します。「このステージに変わったら、この内容を、この経路で届ける」という判断のルールを、あらかじめ用意しておきます。

たとえば、この勤怠管理SaaS企業では、統合したプロファイルをもとに、ステージごとのアクション基準を設計しました。設計フェーズで決めた接点方針を、AIが実行できるルールへと落とし込んだのです。

このように、ステージとアクション基準を設計することが、2つ目のステップになります。

ステップ③ステージ変化の検知からコンテンツ配信・営業通知までをCRMのワークフロー機能で実装する

3つ目のステップは、ステージ変化の検知から、コンテンツ配信や営業への通知までを、AIエージェントで実装することです。なぜなら、判断の基準を、実際に動く自律実行の仕組みへとつなげて初めて、実行フェーズが回り始めるからです。

AIエージェントが、統合プロファイルを見てステージの変化を検知し、設計した基準に沿ってコンテンツを配信し、必要なら営業へ通知します。ここまで実装して、設計した体験が全顧客へ自動で届くようになります。変化を検知して動かす実装はパイプラインの停滞の記事でも扱っています。

たとえば、この勤怠管理SaaS企業では、ステージ変化の検知から配信・通知までをAIエージェントで実装し、実行フェーズを自動で動かせるようにしました。設計と実行の分業が、仕組みとして完成したのです。

このように、検知から配信・通知までをAIエージェントで実装することが、3つ目のステップになります。以上が、Agentic CRMで顧客体験設計を実装する3つのステップでした。

顧客体験設計のフェーズ別KPI

実装できたら、次はその成果をどう測るかです。顧客体験設計の成果は、導入の段階によって見るべき指標が変わります。そこでここでは、フェーズ別のKPIを3段階で整理します。

顧客体験設計のKPIは、導入期はプロファイルの統合カバレッジ、定着期はエンゲージメント率、成果期は顧客LTVの変化で測ります。

フェーズ①導入期：顧客プロファイルの統合カバレッジで測る

導入期は、顧客プロファイルの統合カバレッジで測ります。なぜなら、この段階では、AIが判断するための前提となるデータが、どれだけそろったかが最優先の指標になるからです。

全顧客のうち、マーケ・営業・CSのデータが統合されたプロファイルの割合を見ます。カバレッジが低いままでは、AIの判断も一部の顧客にしか働きません。逆に、ここが十分に高まれば、その後の実行フェーズを全顧客へ広げられます。

たとえば、この勤怠管理SaaS企業では、まず統合カバレッジを指標に置き、全取引社のプロファイルがそろっているかを確認しました。データの統合状況を最初のKPIにしたことで、基盤づくりの進捗が明確になったのです。

このように、導入期はプロファイルの統合カバレッジで測ります。

フェーズ②定着期：パーソナライズされたコンテンツのエンゲージメント率で測る

定着期は、パーソナライズされたコンテンツのエンゲージメント率で測ります。なぜなら、この段階では、AIが実行する個別の対応が、顧客に届いて反応を得られているかが問われるからです。

配信したコンテンツの開封や閲覧、その先の行動といったエンゲージメントを見ます。画一的な配信のときと比べて反応が上がっていれば、実行フェーズが機能している証拠になります。指標の置き方はKPI設計の記事でも扱っています。

たとえば、この勤怠管理SaaS企業では、ステージに合わせて配信したコンテンツの反応率を追い、以前の一斉配信と比べて改善しているかを確認しました。個別化した対応が効いているかを、エンゲージメントで見たのです。

このように、定着期はパーソナライズされたコンテンツのエンゲージメント率で測ります。

フェーズ③成果期：顧客LTVの変化で測る

成果期は、顧客LTVの変化で測ります。LTV（顧客生涯価値）とは、一人の顧客が取引期間を通じて自社にもたらす総利益のことです。なぜLTVで測るのかというと、顧客体験設計の最終的な狙いは、一人ひとりの顧客との関係を長く深くし、事業の成果につなげることだからです。

解約率の低下やアップセルの増加は、最終的にLTVの変化として表れます。個別の対応を続けた結果が、顧客あたりの価値として積み上がります。指標を体系的にそろえたい場合はBtoBマーケティングのKPI設計の記事で扱っています。

たとえば、この勤怠管理SaaS企業では、実行フェーズをAgentic CRMに任せてから半年で、解約率が改善し、既存顧客のLTVが約15%向上しました。「設計した体験を全顧客に同じ水準で届けたい」という当初の目的が、数字となって表れたのです。フェーズ別のKPIをさらに体系的に設計したい場合は、BtoBマーケティングのKPI設計ガイドで解説していますので、ぜひ参考にしてもらえると嬉しいです。

このように、成果期は顧客LTVの変化で測ります。

顧客体験設計を先に始めるべき企業の特徴

フェーズ別のKPIまで見てきましたが、Agentic CRMによる顧客体験設計は、どんな企業にも同じように向くわけではありません。まずは、向いている企業の特徴から整理しましょう。そこでここでは、始めるのに向いている企業の特徴を、3つ挙げます。

Agentic CRMによる顧客体験設計が向くのは、データが同一CRMに集約され、画一的なアプローチに限界を感じ、顧客接点の増加に人員で対応できない企業です。

特徴①マーケ・営業・CSのデータが同一CRM上に集約されている

1つ目の特徴は、マーケティング・営業・CSのデータが、すでに同一のCRM上に集約されていることです。なぜなら、実行フェーズをAIが動かす前提が、統合された顧客プロファイルにあるからです。

データが一つのCRMにまとまっている企業であれば、AIが個別の判断を下すための材料がすでにそろっています。統合の工程を大きく省けるぶん、実行フェーズの構築に早く進めます。

たとえば、この勤怠管理SaaS企業も、営業とサポートのデータを同一の基盤へ集約できる状態にありました。この状態にある企業は、Agentic CRMの効果を早く得やすくなります。

このように、データが同一CRMに集約されていることが、向いている最初の特徴になります。

特徴②セグメント別の画一的なアプローチに限界を感じている

2つ目の特徴は、セグメント別の画一的なアプローチに、限界を感じていることです。なぜなら、Agentic CRMの価値は、セグメント単位の対応を超えて、顧客一人ひとりに合わせて個別に実行する点にあるからです。

年代や業種でセグメントを切って一律に配信する方法では、同じセグメント内の個別の違いに対応できません。もっと細かく一人ひとりに合わせたいという課題を持つ企業ほど、実行フェーズの自動化が効いてきます。

たとえば、セグメント配信を続けてきたものの反応が伸びにくくなったと感じている企業であれば、顧客ごとの個別実行へ切り替える価値があります。画一的な対応への限界感が、導入の動機になります。

このように、画一的なアプローチに限界を感じていることが、2つ目の特徴になります。

特徴③顧客接点の増加に対してCS担当者の数を増やせない課題がある

3つ目の特徴は、顧客接点の増加に対して、CS担当者の数を増やせない課題があることです。なぜなら、実行フェーズをAIが担う最大の効果が、人員を増やさずに対応をスケールできる点にあるからです。

顧客が増え続ける一方で、採用や育成が追いつかない企業は少なくありません。人を増やして対応する方法に限界があるほど、実行をAIに任せる意義が大きくなります。

たとえば、この勤怠管理SaaS企業も、取引社数の増加に対してCS担当者を同じペースで増やせずにいました。この状態にある企業にとって、実行フェーズの自動化は現実的な打ち手になります。

このように、接点の増加に人員で対応できない課題があることが、3つ目の特徴になります。

顧客体験設計を急がなくてよい企業の特徴

一方で、今の段階では向いていない企業もあります。無理に始めても、実行フェーズが機能しないまま費用だけがかかってしまいます。そこでここでは、始めるのに向いていない企業の特徴を、3つ挙げます。

データが蓄積されていない、ステージの基準が合意できていない、個人情報ポリシーが未整備という企業は、まず前提を整えることが先になります。

特徴①CRMへのデータ入力が習慣化されておらずデータが蓄積されていない

1つ目の特徴は、CRMへのデータ入力が習慣化されておらず、データが蓄積されていないことです。なぜなら、AIの判断も実行も、蓄積された顧客データを前提にするからです。

商談や活動の記録が現場で定着していなければ、AIに渡せる材料が乏しくなります。プロファイルを統合しようにも、そもそも中身が入っていない状態では、実行フェーズは動きません。定着まで伴走してほしい場合は、入力が続く形をつくるところから一緒に組み立てられる相手かどうかを見ます。

たとえば、CRMを導入していても入力が一部の担当者に限られている企業では、まずデータ入力を習慣づけることが先になります。データが蓄積されていない段階でAIを入れても、効果は表れません。

このように、データが蓄積されていないことが、向いていない最初の特徴になります。

特徴②顧客ステージの定義やトリガーの基準が社内で合意できていない

2つ目の特徴は、顧客ステージの定義やトリガーの基準が、社内でまだ合意できていないことです。なぜなら、AIが自律的に判断するには、その拠り所となる基準が定まっている必要があるからです。

どの状態をどのステージと呼ぶか、何を行動のきっかけとするかが部門ごとにバラバラでは、AIは一貫した判断を下せません。基準づくりは、実装の前に社内で合意しておくべき工程です。ツール設定ではなく業務設計から入ってほしい場合は、この合意づくりから入れる相手かどうかを見ます。

たとえば、営業とCSでステージの捉え方が食い違っている企業では、まず基準をそろえる議論が先になります。合意のないままAIに任せても、判断が定まりません。

このように、ステージやトリガーの基準が合意できていないことが、2つ目の特徴になります。

特徴③個人情報の取り扱いポリシーが整備されていない

3つ目の特徴は、個人情報の取り扱いポリシーが整備されていないことです。なぜなら、顧客データを扱う以上、収集と利用のルールが定まっていなければ、運用を始められないからです。

どのデータを、どの同意のもとで、何に使うのかが曖昧なままでは、後から利用範囲の見直しを迫られます。ポリシーの整備は、AI活用を始める前提として欠かせません。

たとえば、収集したデータの利用目的や同意の管理が曖昧な企業では、まずポリシーを整えることが先になります。ここが未整備のままでは、安心して実行フェーズを広げられません。

このように、個人情報ポリシーが整備されていないことが、3つ目の特徴になります。

いくらかかる？顧客体験設計の費用感

向き不向きを踏まえて導入を検討するなら、費用の全体像も押さえておきたいところです。Agentic CRMの費用は、大きく3つの要素に分かれます。そこでここでは、顧客体験設計を実現する際の費用感を、3つの観点から整理します。

費用は、CRMと統合基盤のライセンス・AIエージェントの構築支援・実行量に応じたランニングコストという3つの要素で考えます。

費用①CRMとCDPのライセンス費用の目安

1つ目は、CRMと統合基盤のライセンス費用です。これは、契約するエディションや利用規模によって変わるため、一律の金額を示すのは難しいのが実情です。なぜなら、必要な機能やユーザー数、扱うデータ量によって、前提となる契約が変わってくるからです。

すでにCRMを使っている企業であれば、既存の契約に加えて統合基盤の費用を見込む形になります。まず自社の利用前提を洗い出し、そのうえで見積もりを取るのが確実です。

たとえば、この勤怠管理SaaS企業では、すでに契約していたCRMに、プロファイル統合のための基盤を追加する前提で費用を見積もりました。既存の投資を活かしながら、追加分を試算したのです。

このように、ライセンス費用は自社の利用前提をもとに見積もることが出発点になります。

費用②AIエージェント設定・構築にかかる外部支援費用の目安

2つ目は、AIエージェントの設定・構築にかかる外部支援の費用です。これは、実装するユースケースの数と複雑さによって変わります。なぜなら、どこまでの範囲を、どれだけ作り込むかで、必要な工数が変わるからです。

いくつものユースケースを一度に構築すれば費用は大きくなり、まず一つに絞って小さく始めれば抑えられます。自社の体制で対応できる範囲と、外部に任せる範囲を切り分けて考えます。ソリューション営業に特化した支援がほしい場合は、商談の進み方を踏まえて範囲を切れる相手かどうかを見ます。当社のAgentic CRM設計支援では無料相談も受け付けています。詳しくはAgentic CRM設計支援をご覧ください。

たとえば、この勤怠管理SaaS企業では、最初から全接点を作り込まず、効果の見えやすい一つのユースケースから構築を始めました。範囲を絞ることで、初期の外部支援費用を抑えられたのです。

このように、構築支援の費用はユースケースの範囲を絞ることで調整できます。

費用③AIエージェントの処理コストとランニングコストの試算方法

3つ目は、実行量に応じたランニングコストです。実行量に応じた課金とは、AIエージェントが動いた回数に比例して費用が増える課金の形のことです。なぜ試算が必要かというと、消費量は対応する顧客数やアクションの回数によって変わり、事前に正確な額を読みにくいからです。

ランニングコストは、一件の対応でどれだけのアクションが動くかと、対象となる顧客数の掛け合わせで決まります。まず小さな範囲で実際の消費量を計測し、その結果をもとに全体の規模を見積もるのが現実的です。

たとえば、この勤怠管理SaaS企業では、一つのユースケースを一部の顧客で動かして消費量を計測し、そのデータをもとに全社展開時のコストを試算しました。実測を起点にしたことで、費用の見通しを立てられたのです。

このように、ランニングコストは小さく計測してから試算するのが確実です。

【一問一答】Agentic CRMと顧客体験設計に関するよくある質問

最後に、Agentic CRMと顧客体験設計について検索されやすい疑問に、簡潔にお答えします。導入検討で気になる点から順に整理します。

Agentic CRMによる顧客体験設計は、少量のデータからスモールスタートでき、MAの自動化を超えてAIが状況を自律判断する点に本質があります。

質問①どのくらいのデータ量から始められるのか

大量のデータがなくても始められます。この記事で例に挙げた勤怠管理SaaS企業も、営業とサポートで別々のCRMを使ったままの状態から着手しています。まず一つのユースケースと対象顧客を絞れば、限られたデータからでも実行フェーズを動かせます。統合カバレッジを少しずつ広げながら、対象を拡大していくのが現実的な進め方です。

質問②Agentic CRMで実現する顧客体験設計とMAの違いは何か

MA（マーケティングオートメーション）は、あらかじめ設定したシナリオに沿って配信を自動化する仕組みが中心です。一方、Agentic CRMは、顧客のステージ変化をAIが自律的に判断し、状況に応じて個別に実行します。この企業の場合、「料金ページを3回見た」「主要機能の利用が止まった」というトリガーを定義したうえで、その後の打ち手はAI側の判断に任せました。決めた分岐をたどるのか、状況を見て自ら動くのかが、両者を分ける違いです。

質問③プライバシー対応はどうするのか

個人情報保護法やGDPRに沿って、データの収集・利用を設計することが前提になります。この企業では、営業側とサポート側で集めていた情報の範囲が違っていたため、どのデータをどの同意のもとで集め、何に使うかを先に定義しました。あわせて、入力した内容が学習に使われないことを担保する仕組みも、対応を支える要素になります。

質問④BtoBの顧客体験設計でも有効か

有効です。むしろ、検討期間が長く、契約後の関係も続くBtoBほど、顧客ごとの個別対応を実行し続ける価値が大きくなります。この企業も従業員約250名の中堅BtoB SaaSで、取引社数が200社を超えたあたりから担当者が全顧客の状況を追いきれなくなっていました。本記事で見てきた接点別の活用場面も、いずれもBtoBの顧客体験を前提にしたものです。

質問⑤導入にかかる期間の目安はどのくらいか

実装する範囲によって変わります。一つのユースケースに絞ったスモールスタートであれば、比較的短い期間で動かし始められます。この企業が既存顧客のLTVの変化を確認できたのは、実行フェーズを任せてから半年後で、約15%の向上という形で表れました。全社の接点へ広げる場合は、データ統合や基準設計を含めて段階的に進めるのが現実的です。

顧客体験設計の難しさは、全顧客に実行し続けるところにある

顧客体験設計の本当の難しさは、優れた設計を描くことよりも、その設計を全顧客に実行し続けることにあります。本記事では、顧客体験設計を設計フェーズと実行フェーズに分け、実行フェーズをAgentic CRMがどう担うのかを、接点別の活用場面から実装ステップ、フェーズ別のKPIまで、一続きで整理してきました。

設計フェーズは、これまでどおり人が事業の意図を込めて描きます。そのうえで、個別の配信やタイミングの判断、接点ごとの対応という実行フェーズを、Agentic CRMが自律的に引き受けます。この分業が成立したとき、顧客体験設計は担当者の工数に縛られず、全顧客へスケールします。今回例に挙げた勤怠管理SaaS企業も、実行フェーズをAgentic CRMに任せたことで、200社を超える顧客へ設計した体験を同じ水準で届けられるようになり、半年で既存顧客のLTVが約15%向上しました。

顧客体験設計で成果を出す鍵は、設計と実行を分けて考え、人が担う領域とAIが担う領域を見極めることにあります。この見極めができれば、設計して終わりという状態から抜け出し、描いた体験を一人ひとりの顧客へ届け続けられるようになるでしょう。