Latest / M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語） / Dynamics 365 Customer Insights – Data をやさしく解説：顧客データの統合、360度プロファイル、セグメント（AI吹き替え）

Transcript

Dynamics 365 Customer Insights – Data をやさしく解説：顧客データの統合、360度プロファイル、セグメント（AI吹き替え） · M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語）

0:00
マイクロソフト365コパイロット ai アジュールそして働き方の未来を築く人々が集う10日間準備はいいですかこの1月 m 365コンが帰ってきます
0:10
さらに規模を拡大して世界中の mvp や業界エキスパートによるライブセッション実演でも実践的な知識をぜひ体験してください
0:18
ありきたりなスライドや空虚なバズワードは一切ありませんコパイロットスタジオ ai エージェントファブリックセキュリティガバナンス
0:26
自動化といった現実の課題に取り組みます it プロフェッショナル開発者ビジネスリーダーのどなたにも最適なセッションをご用意しています
0:35
10日間のフル開催で多様なテクノロジーを探求し世界中のコミュニティとつながりましょう
0:40
ライブで視聴しすぐに役立つ知見を組織に持ち帰ってください 2027年1月10日間一つのマイクロソフトコミュニティ登録受付を開始しました
0:51
今すぐ参加を確定させましょうサイトはメートル365コンドットネットです
0:58
メートル365コンドットネットから今すぐ登録を1月のライブでお会いしましょうもし一人の顧客が3つのシステムに登録されていてそれぞれが全く異なる情報を伝えていたらどうなるでしょうか
1:09
営業担当者は商談中とみなしサポート担当者は苦情とみなしマーケティング担当者は先週メールをクリックした人として認識します
1:14
ところがその同じ人物がすでに2度も購入を済ませていたとしたらどうでしょう一つの画面だけを見ていては全体像を把握することはできません
1:20
m365fmのミルコピーターズですこのナレッジナゲットでバラバラになった全体像をわかりやすく再構成します
1:25
なぜ顧客データが分散すると深刻な問題が起きるのか企業が顧客をリストの業としてではなく人間として扱うためになぜ共通の視点が必要なのかを解説します
1:34
顧客データの分散がなぜ誤った判断を招くのかあなたが企業向けに機器を販売する会社を経営していると想像してください
1:40
営業チームはダイナミクス365セールスを使用しています彼らは連絡先顧客企業通話履歴会議商談案件見積もり過去のメモを把握しています
1:48
これは営業の準備には役立ちますがあくまで営業システム内の情報にすぎませんサポートチームは全く別のシステムで業務を行っています
1:54
彼らはサービスケース製品の故障質問や苦情問題を解決するためのやり取りを管理していますサポート担当者はその顧客が今月3回問い合わせてきたことを知っていますがその履歴は営業記録には反映されません
2:03
マーケティング部門もまた独自の情報を持っています彼らは誰がメールを開封しリンクをクリックしホームに入力しページを訪問しイベントに登録したかを知っています
2:11
マーケターが新製品への強い関心を見ている一方でサポート担当者はすでに所有している製品に不満を抱く顧客を見ています単純な例え話をしましょう
2:18
バラバラの部屋があるオフィスビルを想像してくださいそれぞれの部屋には専用の窓が一つずつあります営業にはその窓からの景色サポートには別の景色
2:25
マーケティングにはまた別の景色が見えているのです誰も全体像を把握できていません部門間の壁を取り払うまではそこで共有顧客ファイルが役立ちます
2:32
壁を取り払うのです誰も間違ったことはしていません単に目的別に作られた別々の場所に情報が存在しているだけです営業は商談を管理し
2:40
サービスは問題を解決しマーケティングはエンゲージメントを理解する必要があり注文は別のシステムにありウェブサイトの活動は分析ツールに残されています
2:47
その分断が奇妙な状況を生み出します例を挙げましょう
2:51
アレックスモーガンという顧客の例です営業システムでは古い職場メールアドレスとアクティブな商談を持つアカウントとして登録されています
2:57
サポートシステムでは個人のメールアドレスで登録され最近2件の問い合わせがありました
3:02
ウェブサイトでは名前と電話番号だけでウェビナーに登録しましたこれらはすべて同一人物の記録ですがつなぐ方法がないため会社側は3人の別のアレックス
3:12
モーガンがいるとみなしています営業は熱心に売り込みマーケティングはアップグレードを宣伝しサポートは前回の電話と同じ
3:18
詳細を繰り返すよう求めてきますアレックスの立場からはチグハグに感じられます
3:22
あなたも経験があるでしょう問題を問い合わせてはっきりと説明した直後に陽気なメールで追加購入を進められるといった経験です
3:29
会社は情報を持っているのにチーム間で同じ情報を共有できていないのですデータの不整合は小さな問題も引き起こします
3:36
重複した記録はメールの重複を招き古いメールアドレスは本人に連絡が届かない原因となり注文とサービス案件の関連付けが欠けていると顧客が離れた理由が見えなく
3:44
なりますそして人々はリストをスプレッドシートに書き出し始めます
3:47
マーケティングがリストを作り営業が別のリストを作りサービスが独自のレポートを作成しますやがてチームはどのリストが正しいかを議論し
3:54
顧客は誰かが全体像を理解してくれるのを待たされますこれは日々の意思決定に影響します
3:59
営業マネージャーは深刻な問題を抱える顧客に追客しマーケターは定価で購入したばかりの顧客に割引メールを送り
4:05
サービスリーダーは通話相手が最大規模の顧客であることに気づきません解決策はすべてのチームに単一のアプリを強制することではありません
4:12
各チームにはそれぞれの仕事に適したツールが必要です必要なのは別々の記録をつなぐことができる共有顧客ファイルです
4:18
そうすればすべてのチームが同一人物を起点に動けます別人として扱うことはなくそれがカスタマーインサイトデータの本来の姿です
4:25
では各部門に同じアプリの使用を強制することなく異なる顧客記録を統合するにはどうすれば良いでしょうか
4:31
その答えがcdpとも呼ばれるマイクロソフトの顧客データプラットフォームダイナミクス365カスタマーインサイトデータです
4:36
最もシンプルな定義をご紹介します cdpは利用しているあらゆるシステムから顧客データを一箇所に集約し
4:41
同一人物の記録を結びつけてビジネスツールで活用できる永続的なプロファイルを構築します
4:46
大きな保管室を想像してみてくださいすべての部署がその部屋にフォルダを送ります
4:51
営業部門は連絡先や商談履歴を送りますサポート部門は対応記録を送ります
4:55
ウェブサイトからはサインアップやページ訪問のデータが注文システムからは購入や返品のデータが送られます
5:00
そのままの状態ではこれらのフォルダは異なるラベルや形式あるいは異なる顧客番号で管理されているかもしれません
5:05
カスタマーインサイトデータはそれらすべてを整理し関連する記録をまとめて一つの顧客ファイルを作成します
5:10
そのファイルによっていわゆる360度ビューが得られますよく耳にする言葉ですがその意味を説明します
5:15
360度ビューとは一人の顧客に対して複数の種類のやり取りを確認できることを意味します
5:20
誰であるか何を購入したかいつサポートに電話したかそしてオンラインでどのように関与したかといった情報です
5:24
これは魔法ではなくより全体的な把握を可能にするものです顧客データは通常いくつかの一般的なタイプに分類されます
5:29
属性データは名前住所役職会社名などその人を表す情報ですトランザクションデータは購入返品支払い予約サブスクリプションといった取引の記録です
5:39
行動データはメールの開封製品ページの閲覧ホームの入力アプリの利用イベントへの登録といったアクションを記録します
5:46
カスタマーインサイトデータは在庫やサービス情報などの運用データに加えコネクテッドデバイスやiot機器からのデータも取り込むことができます
5:54
コネクテッドマシンを販売する企業は顧客履歴と合わせてマシンの稼働状況を確認したいと考えるでしょう
5:59
サービスチームは顧客から問題についての電話があった際運用データでマシン側からもエラーが報告されていたことを把握できます
6:05
その背景情報が対話の内容を変えるのです
6:08
私がカスタマーインサイトジャーニーズではなくカスタマーインサイトデータと言っている点に注目してください
6:12
どちらもカスタマーインサイトという名前の下にありますが役割は異なります
6:15
データは情報を取り込みプロファイルを準備し有用なパターンを見つけ出します
6:19
ジャーニーズはそれらのプロファイルや顧客グループを使用してメールやテキストメッセージなどのコミュニケーションを送信します
6:24
一方は顧客データを整理理理解する役割を担います
6:27
もう一方はその理解を活用して顧客と対話します
6:30
データを記録保管室ジャーニーズをコミュニケーション窓口と考えると分かりやすいでしょう
6:34
さてこれをダイナミクス365セールスと混同する人が多くいます
6:37
ダイナミクス365セールスは見込み客商談活動アカウントとの対話を追跡することで
6:42
営業担当者が関係構築や営業業務を管理し営業チームが仕事をするための場所を提供します
6:47
カスタマーインサイトデータはより広い視野を提供します
6:50
ダイナミクス365セールスの情報だけでなくサービスシステムやウェブサイト注文システムデータストアその他の承認済みソースからの情報も接続可能です
6:59
これはセールスを置き換えるものではなくセールス単独では把握しきれない顧客の周辺背景情報を保管するものです
7:04
カスタマーインサイトデータはバックエンドでマイクロソフトアジュール上で稼働しており
7:07
マイクロソフトがデータの保存処理保護のためのクラウド基盤を提供しています
7:11
本製品にはプライバシーセキュリティガバナンスのためのツールも含まれています
7:15
ガバナンスとは誰がデータにアクセスでき企業がそれをどう利用できるかを管理する一連のルールのことです
7:20
顧客プロファイルには個人情報が含まれるためこれらのルールは設計の段階から組み込む必要があります
7:25
カスタマーインサイトデータが個々の顧客レコードを一つの有用なプロファイルにする場であると理解できれば
7:30
次の実践的な疑問はそれらすべてのレコードをどうやって同じワークスペースに集めるかということです
7:35
統合顧客プロファイルの構築カスタマーインサイトの導入前データはあらゆるものと接続可能です
7:42
環境を作成します環境とは顧客データを取り込み準備し接続し誰が作業できるかを管理するための制御されたワークスペースと考えてください
7:52
そのワークスペース内でまずデータソースの追加から始めます
7:55
すでにダイナミクス365を利用している場合マイクロソフトデータバースが販売やサービスのレコードを提供することがよくあります
8:01
これはデータバースが多くのダイナミクス365やパワープラットフォームアプリのデータストアとなっているためです
8:05
カスタマーインサイトデータはアジュールデータレークファブリックワンレークアジュールシナプスアナリティクスにも接続できます
8:11
名称は専門的ですが要は企業が大量のデータをクラウドストレージやレポートシステムに保管しているということです
8:16
パワークエリコネクタを使えば別の方法で接続できます
8:20
パワークエリはデータを取り込んで使用前に成形するためのマイクロソフトのツールです
8:24
データベースやビジネスアプリあるいはダイナミクス365のレコードと形式が異なるソース内のデータを扱う際に役立ちます
8:31
各ソースはテーブルとして読み込まれます
8:33
テーブルとはスプレッドシートのような列と行で構成されたリストのことです
8:37
例えば顧客リストのテーブル注文リストのテーブルサービス案件のテーブルウェブサイト登録のテーブルなどがあります
8:43
難しいのはこれらのテーブルで同じ項目名が使われることがほとんどない点です
8:47
あるシステムでは列名がメールアドレスでも別のシステムではeメールだったり
8:54
カスタマー番号に国コードが含まれるソースもあれば省略されるソースもあり名前もスペルスペース継承の扱いが異なる場合があります
9:00
カスタマーインサイトデータには各フィールドが何を意味するのかを理解するための手助けが必要です
9:05
このステップはマッピングと呼ばれます
9:07
取り込むデータ列のどこに氏名メールアドレス電話番号顧客番号住所といった個人を特定するための詳細情報が含まれているかをシステムに教えます
9:15
また人と関連付けられたビジネスレコードもマッピングします
9:18
注文テーブルでは購入履歴を適切な顧客と紐付ける必要がありケーステーブルではサービス履歴を同じ人物と紐付ける必要があります
9:25
こうした関係性がなければ単なるイベントのリストとなってしまい誰のイベントであるかを確実に判断することができません
9:30
レコードの称号とは同一のメールアドレスを探して全て自動的に結合することだと考えるかもしれません
9:35
確かにその場合もありますが実際の顧客データにはより慎重な扱いが求められます
9:39
家族でメールアドレスを共有している場合や顧客が転職して仕事用のメールが変わる場合スペルのわずかな違いで同一人物を示す場合もあれば同性同名の全くの別人がいる場合もあります
9:49
カスタマーインサイトデータでは称号条件を設定できます
9:53
メールアドレスや姓名の組み合わせ電話番号郵便情報に基づいてレコードを称号したりビジネスで利用している場合は顧客番号を使用したりすることも可能です
10:00
目的は同一人物であるという十分な証拠がある場合にのみレコードを接続することです
10:04
次に重複データの削除を行います重複とはソーステーブル内で同じレコードが繰り返し存在する状態を指します
10:10
webホームで送信ボタンが2回押されて2つのエントリーが作成されたり営業データのインポート時に既存の連絡先が再度追加されたりすることがあります
10:15
重複を削除することで本格的な称号作業が始まる前に一人の人間が複数の人物として認識されることを防ぎます
10:21
システムがレコードを称号し重複を削除した後その情報を一つのプロファイルに統合します
10:26
これはよくゴールデンレコードと呼ばれますが少し大げさに聞こえるかもしれません
10:30
そこでよりシンプルな表現を使いましょう
10:32
承認されたレコードからシステムが構築できる最も優れた統合顧客プロファイルです
10:36
あるソースからの現在のメールアドレス別のソースからのアカウントリンク3つ目からの注文履歴そして4つ目からのサービス記録などを集約する可能性があります
10:43
元のシステムが消去されることはありません
10:45
営業システムは営業記録を保持し注文システムは注文データを管理しサポートシステムはケースを管理し続けます
10:50
カスタマーインサイトデータは各ソースの情報を追跡しながら顧客を理解するための連結されたプロファイルを作成します
10:56
その情報のソース出書をたどれることが重要です
10:59
住所や電話番号購入詳細がどこから来たのかと尋ねられたときチームは統合されたプロファイルをブラックボックスとして扱うのではなく元のシステムまで遡って確認できる必要があります
11:07
またプロファイルは時間の経過に伴う活動を含めることでより有用なものとなります
11:12
カスタマーインサイトデータは取り込んだテーブルの活動を接続し時系列のタイムライン上に配置することができます
11:19
月曜の購入木曜のサポートへの電話翌週の製品ページへのアクセス
11:24
それぞれの出来事が顧客と企業の最近の関係性における背景情報を保管します
11:28
営業担当者が顧客に電話をかける前にそのプロフィールを開く場面を想像してみてください
11:32
商談とわずかな通話メモだけでなく直近の注文機能完了したサービス案件最近のイベント登録まで確認できます
11:39
営業担当者は会話の内容を推測する必要はありません
11:42
そのプロフィールが背景情報を提供してくれるからです
11:45
もちろん統合されたプロフィールも最初は単なるデータにすぎません
11:48
次のステップはその情報をチームが活用できる答えへと変えることです
11:51
誰がサポートを必要としているか何が変わったかどのような行動が適切かを判断するために
11:55
そこにメジャー指標データの拡充そして予測による意味付けを加えます
11:59
統合された顧客プロフィールを構築しチームは各顧客をより明確に把握できるようになりました
12:04
しかしティムここからが重要です記録のリストだけではティムあらゆるビジネスの疑問に答えることはできません
12:11
それでも単純な答えが必要になります
12:13
誰が最も頻繁に購入しているか最近注文していないのは誰か
12:16
今月何度もサポートに連絡してきた顧客は誰か
12:19
どの顧客が離脱しそうか
12:20
カスタマーインサイトの出番です
12:22
データはメジャーと呼ばれる手法でこうした疑問の多くに答えてくれます
12:26
ではメジャーとは具体的にどのようなものかを見ていきましょう
12:29
メジャーとはすでに保有しているデータから算出される計算値のことです
12:32
チーム全体で共有し追いかけるための共通の指標だと考えてください
12:36
もう毎回エクセルで手作業で計算してもらう必要はありません
12:39
例えば過去1年間の合計購入額を知りたいならメジャーを作成します
12:43
あるいは最後に注文してから何日が経過したかそれも別のメジャーとなります
12:47
サービス案件の数や平均注文額を算出したりイベントへの参加状況を追跡したりすることも可能です
12:52
どのようなメジャーを使うかはビジネス上何を理解すべきかによって異なります
12:56
サブスクリプション型ビジネスなら顧客期間や利用頻度の低下をメジャーで確認できます
13:01
小売業なら創始出額直近の返品購入感覚などを確認できます
13:06
メジャーはバラバラな行動記録を明確な答えへと変えてくれます
13:09
これにより時間が節約できるだけでなく重要なのはチーム内で定義を統一できる点です
13:13
営業が有料顧客と呼ぶ人とマーケティングが別の基準で算出する対象が異なれば
13:18
顧客体験は再び分断されてしまいます
13:19
共通のメジャーがあれば誰もが同じ視点で疑問に向き合うことができます
13:23
さて顧客プロフィールにはまだ情報の穴がある場合があります
13:26
システム上で氏名や購入履歴は分かっても場所や企業情報といった役立つ情報が欠けているかもしれません
13:33
カスタマーインサイトのデータを使えば承認済みのマイクロソフトやパートナーのデータソースを利用してプロフィールを拡充できます
13:38
データの拡充とはすでに持っているデータに情報を付け加えることを意味します
13:42
カスタマーインサイトは考えられる限りの詳細情報を収集するための口実ではありません
13:46
企業は責任を持って使用できる情報のみを追加すべきでありそれもその顧客データに関する許可やルールに従う場合に限ります
13:52
慎重に使用すればエンリッチメントは欠けている文脈を保管します
13:55
例えば企業向けに販売を行うビジネスでは営業担当者が会話を始める前に最終的に誰と話しているのかを理解できるよう
14:01
営業担当者の連絡先情報に加えて明確な企業情報が必要になることがあります
14:04
次に予測についてです
14:06
カスタマーインサイトのデータには解約の可能性や期待収益を推定するすぐに使えるAIモデルが含まれています
14:11
解約とは顧客が購入をやめるサブスクリプションを解約するあるいは記者との関わりを立つことを意味します
14:16
期待収益とは顧客関係から時間の経過とともに得られる利益を予測するものです
14:20
これらの予測はモデルと提供されたデータに応じて購入履歴最近の活動あるいは行動の変化を考慮しデータ内のパターンを探し出します
14:27
その結果がチームがどこを優先してみるべきかを判断する助けとなるシグナルとなります
14:31
カスタマーインサイトは個人に対する決定を下すものではありません
14:33
解約スコアはその顧客が確実に離脱することを意味するわけではありません
14:36
それは利用可能なデータが以前に離脱した顧客のパターンと類似していることを意味します
14:40
依然として人間が文脈を確認し判断を下す必要があります
14:44
突然購入活動を停止した顧客を想像してください
14:46
予測モデルがその顧客を解約リスクがあるとしてフラグを立てます
14:49
聞き戻しのオファーを送る前にチームがプロフィールを確認すると
14:52
未解決のサービスケースが見つかりました
14:54
この場合どるべき正しい行動は問題を無視した営業メールを送ることではなく
14:57
まずその問題を解決することです
14:59
一部の組織は独自のAIモデルを構築し
15:01
ビジネスに特有の疑問に対してより広範な分析ツールを使用しています
15:04
ある製造業者は製品の使用状況とサービス履歴を合わせて分析しています
15:08
独自のデータサイエンスチームを持つ企業は
15:10
自社のビジネスにとって重要なシグナルに基づいて構築されたモデルをテストしています
15:13
カスタマーインサイトのデータはその作業の一部となり得ますが
15:16
健全なデータや人間によるレビューの必要性を完全になくすものではありません
15:19
ここで重要なポイントをまとめます
15:21
メジャー測定値は何が起きたかを伝えてくれます
15:24
エンリッチメントは文脈を加えます
15:25
予測は確認すべき価値のあるパターンを教えてくれます
15:28
しかしプロフィールの中に留まっているインサイトは最終的には何も変えられません
15:31
チームは誰に連絡しどのようなサポートを提供し
15:34
次に顧客情報をどこに送るべきかを判断する際に
15:36
それらの答えを活用する方法を必要としています
15:38
セグメントとアクティベーションプロフィールを行動へと変えるプロセスです
15:41
顧客プロフィールはそれに基づいて行動を起こせるようになって初めて有用になります
15:44
そこで最終的に登場するのがセグメントです
15:47
セグメントとは設定したルールに基づいて選ばれた顧客の保存済グループです
15:50
それらのルールはカスタマーインサイトデータからのプロフィールの詳細
15:52
活動行動測定値を使用します
15:55
もはやスプレッドシートから手作業で名前を選び出す必要はありません
15:58
その代わりにビジネス上の問いを立てその問いをルールに変換するのです
16:02
例えば過去30日間にサポート案件を作成し
16:05
過去90日間に購入がなく連絡を受け取ることに同意している顧客を表示します
16:10
このグループは顧客情報が変更されると更新されます
16:13
誰かが購入を行うとそのルールに当てはまらなくなりセグメントから外れます
16:17
別の顧客が新しく案件を作成し購入を停止するとセグメントに追加されます
16:20
ターゲット層は古いエクスポートリストになることなく常に顧客情報と結びついています
16:24
これによりチームの働き方が変わります
16:27
サービスチームはセグメントを使用して繰り返し発生する問題により特別なケアが必要な顧客を特定します
16:31
営業チームは最近製品に関心を持ち類似製品の購入履歴がある顧客へのフォローアップに注力します
16:36
マーケティングチームはイベントに参加したが営業担当者との通話をまだ依頼していない人々のオーディエンスを作成します
16:42
重要なのはファンにメッセージを増やすことではありません
16:44
重要なのは次のアクションを会社がすでに把握している情報と適合させることです
16:48
最近トラブルを抱えた顧客には誠実なサービスアップデートが必要です
16:52
数週間新製品を調べている人には役立つ営業の対話が必要です
16:56
両者を同じように扱うことはチームが連携して集めた情報を無視することになります
17:00
カスタマーインサイトデータは統合されたプロファイル、セグメント、その他の準備済みデータを接続された宛先に送信することもできます
17:06
宛先とは情報が必要となる承認済みのツールを指します
17:09
例えばマーケティングプラットフォーム、分析ツール、あるいはチームが顧客と関わるその他の業務システムなどが挙げられます
17:15
ダイナミクス365アプリを使用する組織では顧客カードアドインにより他のダイナミクス365エクスペリエンスに顧客コンテキストをもたらします
17:23
営業担当者やサービス担当者がすでに使用しているアプリで顧客レコードを開く場面を想像してください
17:27
顧客カードはより広範な顧客コンテキストを日常業務の近くに配置するため会話の前に複数のシステムを検索する必要がなくなります
17:35
カスタマーインサイトジャーニーズもこのデータ作業から得られたオーディエンスを使用します
17:38
ジャーニーズはメール、テキストメッセージその他の計画的なインタラクションといった顧客とのコミュニケーションを処理します
17:44
カスタマーインサイトデータが対象者とコンテキストを準備します
17:46
ジャーニーズは会社がコミュニケーションを行うと判断した際にそのオーディエンスを使用します
17:50
これらの役割を分けて考えるようにしてください
17:52
データはこの人は誰か、何を知っているかという問いに答えます
17:55
そしてジャーニーズは次にどのようなコミュニケーションを行うべきかという問いに答えます
17:59
この分離によりチームはよくある間違いを回避できます
18:02
セグメントを作成したからといってその全員に連絡すべきであるとは限りません
18:06
セグメントは事実とルールに基づいてグループを特定するものです
18:10
連絡が適切かどうか、どのチャンネルが適しているか、そして顧客の現在の状況を尊重しているかを判断する人が依然として必要です
18:16
共通のセグメントを使用することでよくあるスプレッドシートの問題も減少します
18:20
マーケティング部門が手作業でクリーンアップしたリストを使い、営業部門が別のバージョンを使い、サービス部門がレポート内に3つ目のリストを隠し持つといったことはなくなります
18:26
各チームが異なる行動を取る場合でもチームは同じ顧客ルールに基づいて作業します
18:30
データは移動できますが制限が必要です
18:32
プライバシー、セキュリティ、そしてCDPの違いについて理解しましょう
18:36
顧客プロファイルが大きくなればなるほど責任も重くなります
18:40
そしてその責任はプライバシーとセキュリティから始まります
18:43
氏名、連絡先、購入記録、サポート履歴、オンラインでの行動を統合する際は情報を扱うための明確なルールが必要です
18:51
接続を開始する前に同意、プライバシー規則、アクセス制御が重要になります
18:55
カスタマーインサイトデータには裏側で機能するプライバシー、セキュリティ、管理ツールが含まれています
19:01
オフィスビルの受付のようなものだと考えてください
19:04
簡単に言えば顧客情報を誰が見ることができ、どのように使用するかというルールを設定するということです
19:09
データを収集、接続、セグメント化、または他のツールに送信する前に顧客の許可について検討します
19:14
重要なのはデータが増えたからといってそれを好きなように使えるわけではないということです
19:17
データは各顧客の許可、法律、および社内ルールに適合している必要があります
19:21
その作業はキャンペーンが失敗した後や顧客から苦情が来る前、最初に行う必要があります
19:24
では、CDPは他の顧客ツールとどう違うのでしょうか
19:27
詳しく見ていきましょう
19:28
一般的な2つの例を比較してみます
19:30
CRMシステムについて考えてみましょう
19:32
ダイナミクス365セールスのようなツールは、営業チームやサービスチームが顧客との直接的な関係を記録し、管理するのに役立ちます
19:38
営業担当者はそれを使用して、リード、商談、通話、アカウントを管理します
19:42
CRMは1つの役割をうまくこなしますが、カスタマーインサイトデータはマーケティングやサービス全体のギャップを埋めます
19:47
カスタマーインサイトデータは、より広範な承認済みソース全体で機能します
19:51
それは記録を統合します