WEBVTT

00:00:00.000 --> 00:00:03.840
コパイロットは質問した時には非常に便利ですが誰も何も尋ねなかったらどうなるでしょうか

00:00:03.840 --> 00:00:08.240
リードは積み上がり問い合わせは未対応のまま請求書は放置されサプライヤーからのメールは届き続けます

00:00:08.240 --> 00:00:11.040
そんな状況でこそダイナミクス365エージェントの出番です

00:00:11.040 --> 00:00:13.480
私はvmのm365担当ミルコピーターズです

00:00:13.480 --> 00:00:18.900
この短い解説が終わる頃にはエージェントの実際の役割働く場所そして人がどのように管理権限を持ち続けるのかを理解できているはずです

00:00:18.900 --> 00:00:20.760
ではエージェントは何が違うのでしょうか

00:00:20.760 --> 00:00:22.340
オフィスビルを想像してみてください

00:00:22.340 --> 00:00:26.060
コパイロットはデスクであなたの隣に座り取り組んでいる作業をサポートします

00:00:26.060 --> 00:00:30.280
エージェントは舞台裏で働く訓練されたスタッフでありあなたが承認した部屋にしか立ち入れません

00:00:30.280 --> 00:00:32.120
勝手に歩き回ることはありません

00:00:32.120 --> 00:00:35.620
ダイナミクス365エージェントとは何か一言で定義しましょう

00:00:35.620 --> 00:00:38.400
まずはダイナミクス365について分かりやすく説明します

00:00:38.400 --> 00:00:42.500
ダイナミクス365はビジネス業務を実行するためのマイクロソフトのコネクテッドプラットフォームです

00:00:42.500 --> 00:00:47.820
顧客記録販売リードサービス案件財務データサプライヤー詳細注文スケジュールなどを保持しています

00:00:47.820 --> 00:00:49.580
これは単一のアプリではありません

00:00:49.580 --> 00:00:55.400
営業チームはリードを扱いサービスチームは案件を扱い財務は口座を管理しサプライチェーンは注文を管理します

00:00:55.400 --> 00:00:58.260
それぞれ異なるアプリを使いますが業務はすべてつながっています

00:00:58.260 --> 00:01:02.640
製品を購入する顧客は販売リードから始まりアカウントとなりやがてサポートへ連絡するかもしれません

00:01:02.640 --> 00:01:06.840
誰かが顧客を支援する際注文履歴支払い履歴過去のサービスチケットのすべてが重要になります

00:01:06.840 --> 00:01:09.540
そのつながったデータこそエージェントが役に立つ場所です

00:01:09.540 --> 00:01:11.340
最もシンプルな定義はこうです

00:01:11.340 --> 00:01:19.800
ダイナミクス365エージェントとはビジネスイベントを監視し承認された情報を見て承認されたルールに従い許可されたアクションを実行しその結果を報告するように設定されたAIです

00:01:19.800 --> 00:01:21.920
承認されたという言葉に注目してください

00:01:21.920 --> 00:01:24.220
エージェントは何にでも自由にアクセスできるわけではありません

00:01:24.220 --> 00:01:28.220
何を読み取り何を変更できるかそしていつ作業を止めて助けを求めるべきかは人が決定します

00:01:28.220 --> 00:01:30.180
では単にコパイロットの名前が変わっただけでしょうか

00:01:30.180 --> 00:01:32.380
いいえコパイロットはその瞬間のあなたを助けます

00:01:32.380 --> 00:01:35.360
案件を開き要約やメールの下書き作成詳細の検索を依頼します

00:01:35.360 --> 00:01:37.240
そうあなたが尋ねたから応答するのです

00:01:37.240 --> 00:01:39.620
しかしエージェントはあなたが離席した後も働き続けます

00:01:39.620 --> 00:01:46.980
例えば受信給を監視して新しいリクエストを検知し関連レコードを確認し回答案を作成し案件を更新して適切な担当者へ作業を割り当てることなどが可能です

00:01:54.220 --> 00:01:57.220
されたルールそして結果を確認するマネージャーを持つ訓練されたチームメンバーです

00:01:57.220 --> 00:02:00.160
さてこう思うかもしれませんそれってただのチャットボットじゃないの

00:02:00.160 --> 00:02:05.000
チャットボットは主に会話をするものですがあおっと質問を入力すると答えが返ってくるか関連記事が案内されます

00:02:05.000 --> 00:02:08.240
それは便利ですが実際の業務は会話だけで完結するわけではありません

00:02:08.240 --> 00:02:13.140
エージェントは会話を出発点として舞台裏でビジネス記録やプロセスと連携して動きます

00:02:13.140 --> 00:02:18.680
例えば顧客からのメールを読み取り顧客を特定しメッセージを既存のケースと紐付け

00:02:18.680 --> 00:02:22.780
承認済みのナレッジ記事を確認し人の判断が必要なら担当者に引き継ぎます

00:02:22.780 --> 00:02:25.560
これは単なる質問への回答以上の大きな仕事です

00:02:25.560 --> 00:02:27.260
エージェントのループはシンプルです

00:02:27.260 --> 00:02:31.060
気づき理解し実行し確認する必要があれば引き継ぎます

00:02:31.060 --> 00:02:34.580
気づきとは新規リードやメッセージなどの特定のイベントを認識することです

00:02:34.580 --> 00:02:37.420
理解とは利用可能なデータやルールを読み取ることです

00:02:37.420 --> 00:02:41.260
実行とは記録の作成やメールの準備など許可された手順を行うことです

00:02:41.260 --> 00:02:47.900
確認とは作業がルールに適合しているかをチェックし制限を超える場合や異常がある場合判断が必要な場合は人間に引き継ぐことです

00:02:47.900 --> 00:02:50.120
エージェントは独立した従業員ではありません

00:02:50.120 --> 00:02:52.060
責任の所在が変わるわけでもありません

00:02:52.060 --> 00:02:54.660
顧客関係の責任は依然として営業担当者が持ちます

00:02:54.660 --> 00:02:56.880
サービス基準の責任はサービスマネージャーが持ちます

00:02:56.880 --> 00:02:59.240
財務上の決定の責任は財務チームが持ちます

00:02:59.240 --> 00:03:04.040
人間が目標を設定し境界線を定義し重要なアクションを承認し結果を確認します

00:03:04.040 --> 00:03:08.920
それでは一件の顧客メッセージを例にこのループが実際にどう機能するかを見ていきましょう

00:03:08.920 --> 00:03:10.540
メッセージからアクションへ

00:03:10.540 --> 00:03:12.980
エージェントが舞台裏でどのように働くか

00:03:12.980 --> 00:03:14.340
想像してみてください

00:03:14.340 --> 00:03:17.280
朝8時15分に顧客からメールが届きました

00:03:17.280 --> 00:03:18.700
荷物がまだ届いていません

00:03:18.700 --> 00:03:20.540
どこにあるか教えてもらえますか

00:03:20.540 --> 00:03:24.160
エージェントがいなければそのメールは共有インボックスに留まったままです

00:03:24.160 --> 00:03:28.440
誰かがそれを開き読み顧客を探し注文を確認しケースを作成しなければなりません

00:03:28.440 --> 00:03:31.500
エージェントがいれば届いたメールがすぐにプロセスを始動させます

00:03:31.500 --> 00:03:34.280
トリガーとはエージェントを起動させるイベントのことです

00:03:34.280 --> 00:03:36.520
それは新しいメールやウェブフォーム新規リード

00:03:36.520 --> 00:03:39.720
納品遅延あるいは不一致な財務取引などかもしれません

00:03:39.720 --> 00:03:42.460
エージェントは社内のすべてを監視しているわけではありません

00:03:42.460 --> 00:03:46.040
許可された給、記録、メールボックスまたはプロセスのみを監視します

00:03:46.040 --> 00:03:48.940
メールが届くとエージェントはコンテキスト、背景情報を必要とします

00:03:48.940 --> 00:03:52.860
注文はどこですか?というメッセージはそれ単体ではほとんど意味をなしません

00:03:52.860 --> 00:03:55.060
エージェントは顧客記録から送信者を特定し

00:03:55.060 --> 00:03:57.500
最近の注文を探し配送状況を確認し

00:03:57.500 --> 00:04:00.380
過去のやり取りを読み承認済みのヘルプ記事を検索する必要があります

00:04:00.380 --> 00:04:03.320
そのコンテキストによって曖昧なメッセージが具体的な作業項目に変わるのです

00:04:03.320 --> 00:04:07.420
エージェントは機能倉庫を出荷されたものの配送業者で遅延が生じている未完了の注文を1件見つけることもあれば

00:04:07.420 --> 00:04:10.080
3件の注文が見つかりどれが該当するのか判別できない場合もあります

00:04:10.080 --> 00:04:11.720
これらは全く異なる状況です

00:04:11.720 --> 00:04:14.700
設定したルールに基づきエージェントは次のステップへ進みます

00:04:14.700 --> 00:04:17.380
単純なケースではサービス案件を作成し

00:04:17.380 --> 00:04:21.040
件名と説明を入力して正しい顧客と注文に紐付けた上で

00:04:21.040 --> 00:04:23.860
承認済みの配送情報を使用して返信を作成します

00:04:23.860 --> 00:04:27.360
状況が不明確な場合は顧客に注文番号を尋ねます

00:04:27.360 --> 00:04:29.400
顧客が緊急契約を結んでいる場合

00:04:29.400 --> 00:04:31.820
エージェントはその案件を優先級に振り分けます

00:04:31.820 --> 00:04:34.800
また遅延によって顧客との約束が守れなくなった場合は

00:04:34.800 --> 00:04:38.100
自動返信で取り繕うのではなく担当者に業務を引き継ぎます

00:04:38.100 --> 00:04:40.240
この最後の部分は非常に重要です

00:04:40.240 --> 00:04:41.840
誤った回答が損失を招いたり

00:04:41.840 --> 00:04:45.520
関係を損なったり会社として守れない約束に繋がったりするような状況では

00:04:45.520 --> 00:04:47.320
エージェントが推測で対応してはなりません

00:04:47.320 --> 00:04:49.380
そこでガードレールが重要になります

00:04:49.380 --> 00:04:51.960
ガードレールとは業務に対する制限のことです

00:04:51.960 --> 00:04:53.980
これにはエージェントが閲覧できるデータ

00:04:53.980 --> 00:04:55.220
編集可能なレコード

00:04:55.220 --> 00:04:57.180
送信できるメッセージ従うべきルール

00:04:57.180 --> 00:04:59.540
そして人の承認が必要なポイントが含まれます

00:04:59.540 --> 00:05:01.800
例えばエージェントにメールのドラフト作成は許可しても

00:05:01.800 --> 00:05:03.580
送信はさせないといった設定が可能です

00:05:03.580 --> 00:05:05.260
案件カテゴリーの更新は許可しても

00:05:05.260 --> 00:05:07.160
返金処理はさせないようにすることもできます

00:05:07.160 --> 00:05:09.800
サプライヤーへの配送状況の問い合わせは許可しつつ

00:05:09.800 --> 00:05:13.000
発注書の変更にはバイヤーの承認を必須とすることも可能です

00:05:13.000 --> 00:05:15.420
エージェントや自動化されたアクションは記録されるため

00:05:15.420 --> 00:05:17.580
後から何が起きたのかを確認できます

00:05:17.580 --> 00:05:19.440
これにより管理者は結果をレビューし

00:05:19.440 --> 00:05:20.820
不適切なルールを修正し

00:05:20.820 --> 00:05:22.580
ある単純な問いに答えられるようになります

00:05:22.580 --> 00:05:24.760
なぜこの案件はその9に送られたのか

00:05:24.760 --> 00:05:27.180
この処理の多くを支えているのがデータバースです

00:05:27.180 --> 00:05:29.860
データバースは多くのダイナミクス365アプリや

00:05:29.860 --> 00:05:32.140
パワープラットフォームアプリで使用される共通データストアです

00:05:32.140 --> 00:05:34.420
ビジネスレコードが関連付けられた引き出しに整理されている

00:05:34.420 --> 00:05:36.140
デジタルファイリングキャビネットと考えてください

00:05:36.140 --> 00:05:40.060
顧客連絡先リード案件活動製品など多岐にわたります

00:05:40.060 --> 00:05:42.100
エージェントは適切な引き出しを見つけて

00:05:42.100 --> 00:05:44.600
適切なファイルが読み取れて初めて十分に機能します

00:05:44.600 --> 00:05:47.360
顧客レコードに重複した名前や不足しているメールアドレス

00:05:47.360 --> 00:05:48.940
古い注文情報などがあると

00:05:48.940 --> 00:05:51.060
エージェントが活用できる情報が減ってしまいます

00:05:51.060 --> 00:05:52.680
メッセージ自体は認識できても

00:05:52.680 --> 00:05:55.940
それを適切な顧客やアクションに確実に紐付けることはできません

00:05:55.940 --> 00:05:57.160
カスタムエージェントの場合

00:05:57.160 --> 00:06:00.000
チームはコパイロットスタジオで業務の構築や管理を行います

00:06:00.000 --> 00:06:01.400
指示を平易な言語で定義し

00:06:01.400 --> 00:06:03.000
承認済みのナレッジソースを接続し

00:06:03.000 --> 00:06:04.120
アクションを追加した上で

00:06:04.120 --> 00:06:05.640
自動的に処理を続行できない場合に

00:06:05.640 --> 00:06:07.100
エージェントがどう対応するかを決定します

00:06:07.100 --> 00:06:09.740
職務記述書の内容が現実のものとなる部分を自動化します

00:06:09.740 --> 00:06:11.700
つまりメッセージからアクションに至るまでの道のりは

00:06:11.700 --> 00:06:12.820
自動化された魔法ではありません

00:06:12.820 --> 00:06:13.960
トリガーが作業を開始させ

00:06:13.960 --> 00:06:15.500
承認済みのデータが文脈を与え

00:06:15.500 --> 00:06:16.640
ルールが選択を制御し

00:06:16.640 --> 00:06:18.040
ガードレールがその範囲を制限します

00:06:18.040 --> 00:06:20.100
そして判断が必要な作業については

00:06:20.100 --> 00:06:21.100
人間が引き継ぎます

00:06:21.100 --> 00:06:22.840
これらの構成要素が揃ったところで

00:06:22.840 --> 00:06:24.780
ビジネス全体でエージェントが対応可能な

00:06:24.780 --> 00:06:26.100
様々な業務を見ていきましょう

00:06:26.100 --> 00:06:27.260
セールスエージェントは

00:06:27.260 --> 00:06:28.880
関心をフォローアップへと変えます

00:06:28.880 --> 00:06:30.440
営業業務は関心とフォローアップの

00:06:30.440 --> 00:06:31.980
ちょうど中間の段階で停滞することがよくあります

00:06:31.980 --> 00:06:33.020
顧客がホームへの記入

00:06:33.020 --> 00:06:33.880
ガイドのダウンロード

00:06:33.880 --> 00:06:35.420
またはメッセージの送信を行います

00:06:35.420 --> 00:06:37.520
リードはダイナミクス365セールスに取り込まれますが

00:06:37.520 --> 00:06:39.400
営業担当者には会議や既存顧客の対応

00:06:39.400 --> 00:06:41.640
さらには優先順位待ちの記録リストが山積みになっています

00:06:41.640 --> 00:06:44.140
そこでセールスエージェントが特定の業務を担うことで

00:06:44.140 --> 00:06:45.000
自動化を実現します

00:06:45.000 --> 00:06:46.660
セールス資格認定エージェントは

00:06:46.660 --> 00:06:48.140
プロセスの最初で機能します

00:06:48.140 --> 00:06:49.480
受信したリードを調査し

00:06:49.480 --> 00:06:51.620
営業チームが設定した適合ルールと比較して

00:06:51.620 --> 00:06:53.860
どのリードを優先すべきかランク付けを支援します

00:06:53.860 --> 00:06:56.320
またパーソナライズされたアウトリーチの準備も行います

00:06:56.320 --> 00:06:59.180
製造業の会社からリードが入ってきたと想像してみてください

00:06:59.180 --> 00:07:02.860
エージェントはダイナミクス365に保持されている詳細情報を確認し

00:07:02.860 --> 00:07:04.940
チームが使用を許可した情報を参照して

00:07:04.940 --> 00:07:07.760
その会社の詳細や関心に基づいたメールを作成します

00:07:07.760 --> 00:07:09.460
営業担当者はそのメッセージを確認

00:07:09.460 --> 00:07:10.740
修正、送信したり

00:07:10.740 --> 00:07:12.420
あるいはそのまま会話を引き継いだりできます

00:07:12.420 --> 00:07:15.380
目的は営業担当者を排除することではありません

00:07:15.380 --> 00:07:17.620
最初の調査を行う時間がなかったために

00:07:17.620 --> 00:07:20.660
有望なリードが手つかずのままになるのを防ぐための自動化です

00:07:20.660 --> 00:07:24.000
マイクロソフトはサンドビックコロマント社による初期の事例を共有しました

00:07:24.000 --> 00:07:25.880
パイロット運用の最初の3週間で

00:07:25.880 --> 00:07:29.580
同社は120時間以上の工数と1万9000ドルの削減を報告しました

00:07:29.580 --> 00:07:32.740
また全面展開後には5%の収益増加が見込まれています

00:07:32.740 --> 00:07:34.500
これらの数字は一つのパイロット事例のものであり

00:07:34.500 --> 00:07:36.200
全ての営業チームに当てはまるわけではありません

00:07:36.200 --> 00:07:39.040
それでもエージェントが解決できるシンプルな課題を示しています

00:07:39.040 --> 00:07:41.200
営業担当者は有益な会話を始める前に

00:07:41.200 --> 00:07:43.220
背景情報を探すことに多くの時間を浪費しています

00:07:43.220 --> 00:07:45.600
セールスリサーチエージェントはその準備作業に集中します

00:07:45.600 --> 00:07:47.600
通話の前に営業担当者は答えを求めています

00:07:47.600 --> 00:07:48.980
この会社はどのような企業か

00:07:48.980 --> 00:07:50.520
どの製品を使っているのか

00:07:50.520 --> 00:07:52.420
以前のメールや会議で何があったのか

00:07:52.420 --> 00:07:54.280
すでに進行中の商談はあるか

00:07:54.280 --> 00:07:56.440
その情報を見つけるには複数の記録を開き

00:07:56.440 --> 00:07:58.280
過去のアクティビティメモを検索する必要があります

00:07:58.280 --> 00:08:00.620
リサーチエージェントが承認済みのコンテキストを統合することで

00:08:00.620 --> 00:08:02.680
営業担当者はより準備を整えて通話を開始できます

00:08:02.680 --> 00:08:04.820
次にセールス商談エージェントがあります

00:08:04.820 --> 00:08:07.780
リードが進行中の商談になると業務内容が変わります

00:08:07.780 --> 00:08:09.600
問いはこの人に連絡すべきか

00:08:09.600 --> 00:08:10.940
から次に何が必要か

00:08:10.940 --> 00:08:13.480
どこで商談が停滞する可能性があるかへと移ります

00:08:13.480 --> 00:08:15.460
オポチュニティエージェントは商談を調査し

00:08:15.460 --> 00:08:17.000
取引の背景を提示し

00:08:17.000 --> 00:08:18.480
発生し得るリスクを指摘して

00:08:18.480 --> 00:08:21.700
営業担当者が注意すべき有望な商談を見つけられるよう支援します

00:08:21.700 --> 00:08:24.500
割引を提供するかどうかを判断する必要はありません

00:08:24.500 --> 00:08:26.200
その代わり判断を下す前に

00:08:26.200 --> 00:08:28.380
営業担当者により明確な状況を提示します

00:08:32.680 --> 00:08:36.760
フローアップ、製品提案、そして企業が定めるルール内での一般的な反論への対応など

00:08:36.760 --> 00:08:39.080
取引を完了へと導くためのサポートを行います

00:08:39.080 --> 00:08:41.040
一般的な流れを考えてみましょう

00:08:41.040 --> 00:08:43.180
月曜の朝に新しいリードが入ってきます

00:08:43.180 --> 00:08:46.280
資格確認エージェントがそのリードが基準に適合しているかを確認し

00:08:46.280 --> 00:08:47.380
アウトリーチの準備をします

00:08:47.380 --> 00:08:49.080
営業担当者が結果を確認し

00:08:49.080 --> 00:08:51.660
実際の会話を開始して顧客のニーズを把握します

00:08:51.660 --> 00:08:55.040
商談が進むにつれオポチュニティエージェントが記録を最新に保ち

00:08:55.040 --> 00:08:56.740
次のステップへの注意を促します

00:08:56.740 --> 00:09:01.420
終盤にはクローズエージェントが取引を停滞させがちな小さな遅延を減らす手助けをします

00:09:01.420 --> 00:09:04.740
しかし関係性の責任を負うのは依然として営業担当者です

00:09:04.740 --> 00:09:08.080
人間は空気を読み顧客を理解しチームの履歴を把握し

00:09:08.080 --> 00:09:12.020
価格を交渉し約束を交わし例外的な対応が必要な時を判断します

00:09:12.020 --> 00:09:15.440
エージェントは作業を準備しフォローアップの抜け漏れを防ぐことはできますが

00:09:15.440 --> 00:09:17.420
結果そのものに責任を持つことはできません

00:09:17.420 --> 00:09:20.860
セールスエージェントは顧客になる可能性のある人々を扱います

00:09:20.860 --> 00:09:25.260
サービスエージェントはすでに顧客が助けを必要としている別の局面を担当します

00:09:25.260 --> 00:09:29.040
カスタマーサービスエージェントはケースが放置されることを防ぎます

00:09:29.040 --> 00:09:32.680
カスタマーサービスはセールスとは異なる種類のプレッシャーを伴います

00:09:32.680 --> 00:09:34.420
セールスリードはしばらく待てますが

00:09:34.420 --> 00:09:37.960
注文の不具合や請求の問題を抱える顧客は回答を急いでいます

00:09:37.960 --> 00:09:42.000
そのためサービスチームはメッセージの確認、ケース作成、給の整理

00:09:42.000 --> 00:09:45.720
そして顧客が実際に助けを得られたかの確認に多くの時間を費やしています

00:09:45.720 --> 00:09:49.320
ケース管理エージェントはそうした初期の管理作業の一部を処理します

00:09:49.320 --> 00:09:54.300
顧客がメールを送ったり、チャットを開始したり、その他のデジタルチャンネルを通じて連絡を取ったりすると

00:09:54.300 --> 00:09:58.380
このエージェントが介入してケースを作成し、メッセージから役立つ詳細を抽出します

00:09:58.380 --> 00:09:58.900
おっと!

00:09:59.040 --> 00:10:05.340
件名を特定し、説明を追加し、顧客レコードを紐付け、適切なカテゴリーにケースを分類します

00:10:05.340 --> 00:10:09.780
サービス担当者は空のホームではなく、使用可能な状態のケースから作業を開始できます

00:10:09.780 --> 00:10:13.480
サブスクリプションが二重請求されました、という顧客からのメッセージを想像してください

00:10:13.480 --> 00:10:20.240
このエージェントは、それを請求の問題として認識し、メッセージを新しいケースに添付して、支払いチームにルーティングします

00:10:20.240 --> 00:10:26.480
担当者は引き続きアカウントを確認して対応を決定しますが、最初に同じ詳細情報を5つのフィールドにコピーする手間は省けます

00:10:26.480 --> 00:10:30.260
カスタマーインテントエージェントは、顧客との会話全体からパターンを探し出します

00:10:30.260 --> 00:10:33.240
インテントとは、お客様が連絡してくる理由そのものを指します

00:10:33.240 --> 00:10:35.180
配送に関する問い合わせでしょうか?

00:10:35.180 --> 00:10:38.440
不具合の報告、解約、あるいは請求書を探しているのでしょうか?

00:10:38.540 --> 00:10:42.920
システムはその理由を検知すると、適切な給や回答ルート、あるいは担当者へと振り分けます

00:10:42.920 --> 00:10:46.120
また、お客様がサポートに連絡し続ける新たな理由も見つけ出します

00:10:46.120 --> 00:10:50.160
例えば製品アップデートの後、お客様から突然同じ質問が寄せられるといった状況です

00:10:50.160 --> 00:10:56.160
ヘルプセンターにまだ記事がない場合、受信トレイが溢れる前にサービスチームへ対応の必要性を知らせます

00:10:56.160 --> 00:10:58.760
次は、顧客ナレッジ管理エージェントです

00:10:58.760 --> 00:11:06.440
サポートチームは一般的な質問への回答を知っていても、それが古いケースノートやチャットの記録、あるいは個人の経験の中に埋もれていることがよくあります

00:11:06.440 --> 00:11:12.140
このエージェントは完了したケースを確認してナレッジベースの不足文を見つけ、記事の下書き作成を支援します

00:11:12.140 --> 00:11:14.340
下書き、という言葉が重要です

00:11:14.340 --> 00:11:20.960
特に返金、契約、安全、製品説明に関わる内容は、顧客向けのコンテンツとして公開する前に必ず人が確認すべきです

00:11:20.960 --> 00:11:26.860
しかしエージェントは繰り返される質問をいち早く捉え、数ヶ月後に誰かが探し出すのを待つのではなく、必要な情報をまとめてくれます

00:11:26.860 --> 00:11:29.700
均質評価エージェントは、また別のレベルで機能します

00:11:29.700 --> 00:11:35.040
手動の確認には時間がかかるため、多くのサービスマネージャーは通話、チャット、メールのごく一部しかレビューできません

00:11:35.040 --> 00:11:39.800
しかしこのエージェントは、管理者が定義した基準に基づいて、より多くのお客様とのやり取りを評価します

00:11:39.800 --> 00:11:46.560
担当者が問題を正しく確認したか、承認された言葉を使ったか、詳細を正しく記録したか、あるいは明確な次のステップを提示できたかなどを確認するかもしれません

00:11:46.560 --> 00:11:53.340
エージェントは管理者がより多くの会話からパターンを把握できるように支援するため、指導は無作為なサンプルではなく、真の課題に集中できます

00:11:53.340 --> 00:11:56.440
コパイロットとエージェントは、サービス現場で連携して働きます

00:11:56.440 --> 00:12:02.940
サービス担当者は、対応中にコパイロットを使って長い会話を要約したり、承認されたナレッジを検索したり、回答の下書きを作成したりできます

00:12:02.940 --> 00:12:10.300
その間、サービスエージェントはケースの作成、インテントの特定、ナレッジ不足の検知、品質レビューなど、バックグラウンドのプロセスを進め続けます

00:12:10.300 --> 00:12:14.540
新製品リリース後に同じ質問が繰り返される状況を想像してください

00:12:14.540 --> 00:12:23.720
インテントエージェントが質問の種類を認識し、セルフサービスで解決できない場合は、システムが適切な回答へ誘導するか、担当チームへケースを振り分けます

00:12:23.720 --> 00:12:29.540
その後、ナレッジエージェントが多くのケースにまたがる同じ質問に気づき、より良いヘルプ記事のための資料を作成します

00:12:32.940 --> 00:12:44.680
エージェントが提携業務を片付けることで、人間は自身の判断が結果を左右するようなケースにより多くの時間を避けるようになります

00:12:44.680 --> 00:12:52.560
この同じパターンは、顧客のインボックスを超えて、注文、サプライヤーへのフォローアップ、スケジュール、そしてチームが日々追いかけざるを得ない財務業務にまで及びます

00:12:52.560 --> 00:12:57.460
財務、オペレーション、サプライチェーンの各エージェントが、誰もやりたがらない作業を代行します

00:12:57.460 --> 00:13:01.580
ビジネスにおける業務の一部は、顧客ケースや営業リードとして送られてくるわけではありません

00:13:01.580 --> 00:13:11.180
それは、システムへの入力が必要な注文メール、配送確認が来ないサプライヤー、未承認のままのタイムシート、あるいは会計期間末に数字が合わないといった形で発生します

00:13:11.180 --> 00:13:16.880
こうした業務は単調な繰り返しですが、資金繰り、顧客との約束、そして日々の運営に影響を与えます

00:13:16.880 --> 00:13:21.700
ダイナミクス365ビジネスセントラルでは、販売注文エージェントが顧客からの注文受付を支援します

00:13:21.700 --> 00:13:30.240
メールで送られてきた注文リクエストを読み取り、ビジネスセントラルから顧客を特定し、注文品目と数量を抽出して、確認用の注文情報を作成します

00:13:30.240 --> 00:13:34.480
昼食前までに、あなたのチームは20件もの注文メールを処理しなければならないかもしれません

00:13:34.480 --> 00:13:41.640
支援がなければ、誰かが各メッセージを開き、送信者を確認し、製品を検索し、詳細を注文書にコピーし、情報の欠落をチェックしなければなりません

00:13:41.640 --> 00:13:49.540
エージェントが最初の処理を担うことで、担当者は例外事項、異常な価格設定、製品の欠落、あるいは顧客の通常のパターンと異なる注文の確認に集中できます

00:13:49.540 --> 00:13:55.180
つまり、チームは情報の再入力にかける時間を減らし、本当に注意が必要な注文への対応に時間を避けるようになるのです

00:13:55.180 --> 00:13:58.500
サプライチェーンチームも、サプライヤーとの間で同様の問題に直面しています

00:13:58.500 --> 00:14:03.260
バイヤーが発注書を送り、確認を待ち、返信がなければサプライヤーを採測します

00:14:03.260 --> 00:14:10.080
ようやく回答が届いても、誰かがそれを読み、正しい発注書と照らし合わせ、次の対応を決定しなければなりません

00:14:10.080 --> 00:14:16.120
サプライヤーコミュニケーションエージェントは、ダイナミクス365サプライチェーンマネジメント内で、こうしたフォローアップ業務を支援します

00:14:16.120 --> 00:14:26.220
サプライヤーに発注書の確認や配送状況の更新を促すリマインダーを送信し、届いたメールを整理して正しい注文と紐付け、購買チームが設定したルールに従って回答します

00:14:26.220 --> 00:14:31.360
バイヤーは、設定した日数が経過した後にエージェントが丁寧なリマインダーを送るように設定できます

00:14:31.360 --> 00:14:42.120
しかし、生産停止につながるような遅延が報告された場合は、エージェントはその問題をバイヤーやプランナーにエスカレーションし、別のサプライヤーへの連絡やスケジュールの変更、あるいは顧客への直接の連絡といった判断を仰ぎます

00:14:42.120 --> 00:14:46.880
財務チームにも独自の参席する業務があり、その多くは称号に関連しています

00:14:46.880 --> 00:14:53.900
ダイナミクス365ファイナンスの環状称号エージェントは、補助元町と総環状元町の取引を比較する作業を支援します

00:14:53.900 --> 00:14:58.080
簡単に言えば、一致するはずなのに一致していない記録を特定するのです

00:14:58.080 --> 00:15:06.860
期末になって不一致を発見するのではなく、エージェントが早期に債を検出し、解決策を提案し、取引の称号と決済作業をサポートします

00:15:06.860 --> 00:15:10.520
相違が何を意味するのかを判断するのは依然として会計士の役割です

00:15:10.520 --> 00:15:16.060
不一致は、タイミングのズレや入力漏れが原因かもしれませんし、調査が必要な深刻な問題の兆候かもしれません

00:15:16.060 --> 00:15:22.140
エージェントはそうした不一致の発見や分類を支援しますが、最終的な判断を下す財務上の洞察にとって変わるものではありません

00:15:22.140 --> 00:15:29.280
財務称号エージェントは、財務報告に向けた称号業務のために、チームがデータを準備、整理するプロセスを支援します

00:15:29.280 --> 00:15:34.300
スプレッドシートのデータ整合性に何時間も費やした経験がある人なら、その利便性は理解できるはずです

00:15:34.300 --> 00:15:39.560
最終的な確認は必要ですが、エージェントが手作業の整理を減らすことで、財務チームはより深いチェックに集中できます

00:15:39.560 --> 00:15:42.500
フィールドサービスには、また別の変動要素が存在します

00:15:42.500 --> 00:15:49.680
歯医者担当者は、交通状況やキャンセル、ダブルブッキング、急な依頼に対応しながら、技術者、機材、顧客訪問のスケジュールを管理しなければなりません

00:15:49.680 --> 00:15:58.460
スケジューリング運用エージェントは、企業が設定した目標とルールに基づいてスケジュールを最適化し、計画が実際の状況に合わなくなった際の変更を支援します

00:15:58.460 --> 00:16:05.520
どの顧客に特別な配慮が必要か、どの技術者が適任か、また最短ルートよりも約束の履行が優先されるべき時はいつか、といった判断は歯医者担当者が行います

00:16:05.520 --> 00:16:09.060
エージェントは調整を助けますが、最終決定権は歯医者担当者にあります

00:16:09.060 --> 00:16:13.200
プロジェクト運用には、たまりがちな事務作業を担当するエージェントも含まれます

00:16:13.200 --> 00:16:27.180
勤怠入力エージェントはプロジェクトの割当てから工数データを準備し、経費エージェントは領収書から詳細を読み取って経費登録を行い、承認エージェントは規定に基づいて内容を精査してからマネージャーに届けます

00:16:27.180 --> 00:16:29.080
結果はシンプルです

00:16:29.080 --> 00:16:37.780
データの転記や送付し忘れのメールが減り、人間が立ち止まって考え、判断すべき例外的な事案に割く時間が増えるのです

00:16:37.780 --> 00:16:43.680
とはいえ、誰も理解していないプロセスや、誰も信頼していないデータをエージェントが修正することはできません

00:16:43.680 --> 00:16:46.160
これこそが、まず整えるべき土台です

00:16:46.160 --> 00:16:47.300
要点はこうです

00:16:47.300 --> 00:16:50.540
エージェントを導入する前に、繰り返し発生する仕事を一つ選んでください

00:16:50.540 --> 00:16:54.760
手順が明確で、担当者がはっきりしており、結果を測定できる仕事を選びましょう

00:16:54.760 --> 00:17:02.620
例えば、サプライヤーの確認にかかる時間や、営業リードへの初回返信率、あるいは問い合わせが最初から適切な担当者に届く割合などです

00:17:02.620 --> 00:17:05.440
社内で最も複雑なプロセスから始めてはいけません

00:17:05.440 --> 00:17:09.680
優れた業務とは何か、について共通認識がある部門から始めるのが正解です

00:17:09.680 --> 00:17:12.080
まずは、ビジネスデータの整備が不可欠です

00:17:12.080 --> 00:17:19.200
一つの顧客が複数の名前で登録されていたり、製品詳細が不完全であったり、サプライヤーの連絡先が古かったりすれば、エージェントはそこにあるデータでしか動けないからです

00:17:19.200 --> 00:17:22.720
動作は早いかもしれませんが、スピードだけでは不適切なデータから良い結果は生まれません

00:17:22.720 --> 00:17:25.600
整理された一貫性のある記録こそが、エージェントの確固たる基盤となります

00:17:25.600 --> 00:17:27.660
次に、その仕事を平易な言葉で書き出してみましょう

00:17:27.660 --> 00:17:35.620
何が作業を開始させますか?エージェントはどの記録を読み取れますか?どのようなアクションを実行できますか?どの操作に承認が必要ですか?そして、いつ作業を停止して人間に引き継ぐべきですか?

00:17:35.760 --> 00:17:38.540
これらは基本的な質問に思えますが、後々の混乱を防ぐために重要です

00:17:38.540 --> 00:17:41.080
サプライヤーへのフォローアップを行うエージェントを想像してください

00:17:41.080 --> 00:17:44.800
納期を問い合わせることは許可しても、価格の変更合意はさせないといった設定が可能です

00:17:44.800 --> 00:17:49.620
あるいは、顧客への返信案を作成させることは許可しても、返金を約束する謝罪メールを送信させないようにすることもできます

00:17:49.620 --> 00:17:53.060
明確な境界線が、ビジネスとエージェントを使うユーザーの両方を守ります

00:17:53.060 --> 00:17:54.580
アクセス権も重要です

00:17:54.580 --> 00:17:58.380
エントラーIDは、マイクロソフトサービス全体のIDと権限を管理します

00:17:58.380 --> 00:18:03.580
部屋への入室許可と、入室後の行動を管理する受付係のようなものだと考えてください

00:18:03.580 --> 00:18:07.680
エージェントは、その特定の仕事に必要な記録とアクションだけにアクセスすべきです

00:18:07.680 --> 00:18:13.720
営業担当エージェントに財務記録の変更権限は不要ですし、サプライヤー担当エージェントに全ての顧客ケースへのアクセス権は必要ありません

00:18:13.720 --> 00:18:17.880
アクセスを制限することで業務の焦点が絞られ、万が一の際のリスクも軽減されます

00:18:17.880 --> 00:18:20.940
重要な局面では、必ず人が関与するようにしてください

00:18:20.940 --> 00:18:27.920
資金の移動、契約条件、顧客への約束、特殊なケース、法的問題、機密データには、全て人間の明確なレビューポイントが必要です

00:18:27.920 --> 00:18:34.160
エージェントは作業の準備、事実の収集、迅速な振り分けを行いますが、ビジネス上の重大なリスクを伴うアクションは人が承認すべきです

00:18:34.160 --> 00:18:36.300
本格導入の前にテストが必要です

00:18:36.300 --> 00:18:39.280
厄介な事例を含め、実際のケースでエージェントを動かしてみましょう

00:18:39.280 --> 00:18:43.020
何を読み取り、何を作成し、何を修正し、どこで停止したかを確認してください

00:18:43.020 --> 00:18:48.900
次に活動記録を見直し、現場の担当者の意見を聞き、より多くのプロセスを任せる前に指示を改善してください

00:18:48.900 --> 00:18:51.080
利用状況の監視も必要になります

00:18:51.080 --> 00:18:56.340
ダイナミクス365のエージェントは、コパイロットクレジットを使用し、これは消費ベースのモデルに従います

00:18:56.340 --> 00:18:58.520
ダイナミクス365のモデル