Agentforceのユースケースの選び方は？どの業務から始めるかを決める5つの判断軸

Agentforceの導入は決まったのに、どの業務から始めるかが決まらないまま時間だけが過ぎている、という状態になっていないでしょうか。機能の一覧をどれだけ読み込んでも、自社のどの業務に当てはめるべきかまでは書かれていません。

本記事では、Agentforceのユースケースを業務の側から選ぶための5つの判断軸と、選んだ業務のどこまでをエージェントに任せるかを決める考え方を整理します。なお本記事は2026年8月時点の情報です。

この記事を書いた人

本田正憲

合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援を提供している。

Agentforceのユースケース選定で迷う3つの状況

Agentforceのユースケース選定でつまずくのは、製品の理解が足りていないからではありません。候補となる業務は社内から挙がってきているのに、そのどれを最初に選ぶのかを決める基準が社内にない、という状態のまま止まります。そこでここでは、Agentforceのユースケースを決められないまま時間が過ぎていく3つの状況を整理します。

Agentforceのユースケース選定が止まる状況には、候補を評価する基準を社内に持っていないという共通点があります。

状況①候補業務が並んだまま優先順位を決められない

1つ目は「候補業務が並んだまま優先順位を決められない」という状況です。各部門から要望を集めた段階では、どの業務にもエージェントへ任せたい理由があり、並べただけでは順番がつきません。

たとえば、従業員300名規模の産業機器メーカーで営業企画を担当しているとします。Agentforceの導入は決まり、来期の予算も確保できているのに、候補として挙がった業務は次の6つのまま2か月が過ぎています。

①見積照会への一次回答・・・標準品の価格と納期を調べて営業担当へ返します ②商談前の下調べ・・・過去の類似案件と、そこで使った提案の切り口を集めます ③展示会で集めたリードへの初回連絡・・・名刺情報をもとに最初のメールを送ります ④特注仕様の価格交渉に向けた条件のすり合わせ・・・値引きの範囲と納期を詰めます ⑤代理店からの技術的な問い合わせへの回答・・・仕様や互換性の質問に答えます ⑥返品・特別対応の例外処理・・・通常の手順に収まらない依頼を個別に判断します

この6つは、担当する部門も、発生する頻度も、失敗したときの影響もばらばらです。会議のたびに推す業務が入れ替わるのは、担当者の意見が割れているからでも、候補が多すぎるからでもありません。6つを比べる項目を先に決めていないからです。

状況②小さく試せと言われたが切り方が分からない

2つ目は、上長から「まず小さく試せ」と言われたものの、その小さくの切り方が決まらない状況です。小さく始めるという指示は、対象の業務を減らすことなのか、使う人数を減らすことなのか、期間を短くすることなのかで、実際にやることがまったく変わります。

先ほどの産業機器メーカーでも、6つのうち3つを同時に試す案と、1つの業務を営業部門の全員に配る案が並んだままになっています。前者は対象が広いぶん、どの業務の結果なのかを後から切り分けられません。後者は利用者が広いぶん、担当者からの問い合わせに営業企画の時間が取られ、検証の記録が薄くなります。どちらも「小さく」という言葉には収まっているのに、検証としての形が違います。さらに期間だけを1か月へ縮める案も出ていますが、1か月目は設定と調整に時間を使うため、担当者が自分の判断で使い始める前に検証が終わってしまいます。

小さく始めるという指示は、何を限定するのかを決めて初めて実行できる指示になります。限定する対象を先に決めておけば、上長への報告も「1つの業務を、1つのチームで、3ヶ月」という形でそろえられるでしょう。

状況③どの業務なら効果が出るのか判断できない

3つ目は、候補のうちどれなら効果が出るのかを、始める前に判断できない状況です。他社の活用事例を集めても、業種も規模も自社と違うため、そのまま自社の候補業務に当てはめる根拠にはなりません。

では、なぜ効果の見込みを事前に判断できないのでしょうか。それは、効果を左右するのが業務の性質であり、その性質を見るための項目を社内で決めていないからです。

この産業機器メーカーの候補でいえば、見積照会への一次回答と商談前の下調べのどちらが効くかを比べようとしても、比べる項目が決まっていません。発生する件数で比べるのか、参照する情報の所在で比べるのか、失敗したときの影響で比べるのかによって、残る業務は入れ替わります。件数で並べれば代理店からの技術的な問い合わせが上に来ますが、失敗したときの影響で並べると同じ業務が下に落ちます。営業企画の担当者が「たぶんこれが効く」という感覚から抜け出せないのは、この項目が空白のままだからです。

効果が出るかどうかは、業務の性質から始める前に判定できます。判定する項目を決めることが、Agentforceのユースケース選定で最初に取り組むことになります。

AgentforceのPoCが止まる3つの原因

前章では、Agentforceのユースケース選定が止まる3つの状況を整理しました。この状態のまま候補を1つ選んで検証に入ると、PoC（概念実証）が結論を出さないまま終わってしまいます。検証の期間が終わっても続けるかどうかを決められないという止まり方は、Agentforceの機能の評価とは別のところで起きています。そこでここでは、AgentforceのPoCが止まる原因を、業務選定という一点に絞って整理します。

AgentforceのPoCが止まる原因は、機能の不足ではなく、最初に選んだ業務の性質にあります。

原因①効果が見えにくい業務を最初に選んだから

最初に挙げたいのは、そもそも効果が見えにくい業務を検証の対象にしてしまうことです。検証の期間が終わっても「悪くはないが、続ける根拠にはならない」という結論になり、次の判断ができないまま自然に止まります。

効果が見えにくい業務には、共通する性質があります。発生する件数が少ないため比較する母数がそろわないこと、そして作業にかかっていた時間が記録として残っていないことの2つです。この2つがそろうと、エージェントが正しく動いていても、動く前との差を示せません。

産業機器メーカーの候補でいえば、返品・特別対応の例外処理がこれに当たります。年に数回しか起きないため検証期間中に数件しか発生せず、しかも1件ごとに手順が違うので、比較の起点になる数字が社内のどこにも残っていません。

この業務をそのまま検証の対象に選んだ場合、止まるのはデータが集まらない段階ではなく、結論を出す段階になります。エージェント自体は動き、対応した記録も残るのですが、比べる相手になる数字が最初からないため、報告会に集まるのは担当者ごとの印象だけです。続けるという判断にも、やめるという判断にも根拠がそろわず、検証の期間だけが消化されます。

逆にいえば、検証を始める前に「この業務は差を示せる形になっているか」を確かめておけば、この止まり方は避けられます。効果の見えやすさは、エージェントの完成度より前に、業務の側で決まっているというわけです。

原因②参照するデータが揃っていない業務だったから

次に多いのが、エージェントが参照する情報がCRM（顧客関係管理）の外にある業務を、検証の対象に選んでしまうことです。検証の初日から情報を集める作業が始まり、エージェントの設定に入る前に期間を使い切ります。

この止まり方は、ナレッジを整備しなかったという手順の抜けとは性格が違います。整備の量が読めない業務を選んだという、選定の段階での判断が原因になっています。

具体例でいうと、この産業機器メーカーの候補②商談前の下調べがそれに当たります。過去の類似案件の情報は、営業担当それぞれのファイル共有フォルダや、送受信したメールの中に残っています。CRMに登録されているのは商談の金額と結果だけで、提案の切り口までは入っていません。エージェントに任せる前に、どこから何を集めるかを決める作業が必要になり、その作業の見通しが立たないまま検証の期間が終わります。

参照するデータがどこにあるかは、業務ごとに決まっている性質であり、候補を挙げた時点で判定できます。この判定を選定の前に置くかどうかで、検証が結論まで届くかが変わってきます。

原因③検証の合格ラインを決めないまま始めたから

3つ目に挙げたいのは、何をもって続ける、あるいはやめると判断するのかを、開始前に決めていないことです。検証が終わったあとに関係者を集めても、判断の材料が人によって違うため、結論が出ないまま解散します。

合格ラインは、検証を始める前にしか決められません。なぜなら、始めたあとに決めようとすると、出てきた結果を見てから基準を作ることになり、その基準に説得力がなくなるからです。

この産業機器メーカーが見積照会への一次回答で検証を始めるなら、決めておくのは「どの記録を、どの状態になったら続けると判断するか」の1点です。ここが空白のまま3ヶ月を過ごすと、報告会では「そこそこ使えた」「思ったほどではなかった」という感想が並び、次のユースケースへ進むのか、この業務を作り込むのかを選べません。

開始前に決めた合格ラインは、検証の途中で対象を広げたくなったときの歯止めにもなります。合格ラインを先に置くことは、Agentforceのユースケース選定の一部だと考えます。

Agentforceより先に業務を決める3つの理由

ここまで、AgentforceのPoCが止まる原因を業務選定の側から見てきました。ここから先は、その順序を「機能より先に業務を決める」という形で確定させます。この順序を逆にすると、Agentforceの機能の一覧を見ながら当てはめられそうな業務を探すことになり、候補の絞り込みが担当者の感覚の話へ戻ってしまいます。そこでここでは、Agentforceの機能を調べる前に業務を決めるべき理由を3つに分けて整理します。

Agentforceのユースケースは、業務の性質から候補を絞ったあとに機能を当てはめる、という順序で決まります。

理由①同じ機能でも業務によって成果が変わるから

まず押さえておきたいのは、同じ機能を使っても、当てはめる業務によって出てくる結果が変わることです。機能の性能が一定でも、その機能が処理する対象の性質がばらつけば、結果はばらつきます。

たとえば、社内の情報を検索して回答を組み立てるという同じ働きでも、参照先が製品カタログのように更新の頻度が決まっているものであれば、回答は安定します。一方で、参照先が営業担当それぞれの商談メモであれば、書き方も粒度も人によって違うため、同じ働きをさせても回答の質は安定しません。

この差は機能の設定では埋まらず、業務の側で参照先を決めるところから始めることになります。機能の一覧を先に読むと、この差が見えないまま「できること」だけが頭に残ってしまいます。

Agentforceの機能を一覧で把握したい場合は、ほか記事「Agentforceの機能一覧｜360・Coworker・Voiceまで主要機能を整理」にて解説していますので、ぜひ参考にしてもらえると嬉しいです。本記事では、その手前にある業務の選び方だけを扱います。

理由②業務が決まらないと必要なデータを特定できないから

次に挙げたいのは、対象の業務が決まらないかぎり、どのデータを用意すればよいかを特定できないことです。データを先に整えようとしても、どこまでを対象にすればよいのかが決まらず、作業が終わりません。

エージェントが参照するデータは、業務の中で担当者が実際に開いている情報とほぼ重なります。そのため、業務を1つに決めた瞬間に、必要なデータの範囲も決まります。

先ほどの産業機器メーカーで見積照会への一次回答を選ぶなら、必要になるのは製品マスタと在庫の情報、標準価格表、そして標準納期の一覧です。ところが商談前の下調べを選んだ場合は、必要になるのが過去案件の議事録と提案書に変わり、用意する対象がまったく入れ替わります。業務を決めずにデータの整備から着手すると、この入れ替わりを何度も繰り返すことになってしまいます。データを整えるという方向は正しくても、範囲を決める前に着手すると、どこまでやれば終わりなのかを社内で説明できません。

必要なデータの範囲を決めるのは業務のほうであり、データの準備量で候補を比べたいときも、先に業務を1つに置いてから見積もるほうが確実です。

理由③評価の基準は業務ごとにしか決められないから

3つ目に、検証の評価基準は業務ごとにしか決められない、という制約があります。全社で共通の基準を作ろうとすると、どの業務にも当てはまるが、どの業務も判定できない基準ができあがります。

評価の基準が業務ごとになるのは、その業務で「うまくいっている状態」の定義が違うからです。問い合わせへの回答であれば、担当者が回答をそのまま使えたかどうかを見ます。リードへの連絡で基準になるのは、送った相手から返信があったかどうかです。社内向けの情報検索なら、担当者が探すのをやめて本来の業務へ戻れたかを確認します。

この産業機器メーカーが6つの候補に共通の基準を作ろうとすると、「担当者の負担が減ったか」といった表現に落ち着きます。ところがこの表現では、返品の例外処理と見積照会の一次回答を同じ物差しで判定することになり、どちらも「多少は減った」で終わります。判定できない基準のまま3ヶ月を過ごすと、続けるかどうかの結論も、次にどの業務へ広げるのかの判断も出せません。

評価の基準を決められるのは、業務を1つに絞ったあとです。基準を言葉にできない段階であれば、まだ業務が絞れていないと判断しましょう。

Agentforceのユースケースを選ぶ5つの判断軸

前章までで、機能より先に業務を決めるという順序を確定させました。ここからは、その業務をどの項目で評価するのかを、5つの判断軸として具体化していきます。そこでここでは、Agentforceのユースケースを選ぶための判断軸を、確認する手順とあわせて整理します。

候補業務は1つの基準では決まらず、発生頻度・判断の定型度・データの有無・失敗時の影響範囲・測定可能性の5つをそろえて見たときに残るものが初手の候補になります。

判断軸①同じ業務が月単位で繰り返し発生していること

1つ目は「同じ業務が月単位で繰り返し発生していること」です。確認するのは、直近3か月ぶんの発生件数を候補業務ごとに数えることで、ここで数えられない業務は、記録が残っていない時点で対象から外して扱います。

件数を数えられないことには、もう1つの意味があります。発生の記録がない業務は、あとで効果を測るときの起点も取れないため、判断軸⑤の測定可能性でも同じように落ちます。

先ほどの産業機器メーカーの候補で数えてみると、展示会で集めたリードへの初回連絡は、展示会が開かれた月だけに件数が集中していました。返品・特別対応の例外処理は、3か月ぶんを数えても数件しか出てきません。一方で見積照会への一次回答と代理店からの技術的な問い合わせは、どの月もほぼ同じように発生していました。

落ちる条件は、発生が特定の月に偏っていること、そして年単位のイベントに紐づいていることの2つです。件数が多いことだけを見て選ぶと、次の判断軸②で止まる業務を選んでしまうため、ここは5つのうちの1つとして扱いましょう。

判断軸②判断の手順が毎回同じ形に収まること

2つ目の判断軸は、その業務で発生する判断の手順が、毎回同じ形に収まることです。確認の方法は、同じ業務の直近5件を並べ、判断の分岐が同じ順序で起きているかを見るというものになります。

ここで大切なのは、担当者の感覚で判定しないことです。「毎回違う」と感じている業務でも、実物を5件並べると同じ順序に収まることがあり、逆に「定型だ」と思われている業務で担当者ごとに順序が違うこともあります。並べるのは直近の5件で足り、それ以上さかのぼると当時の運用と現在の運用が混ざってしまいます。

この産業機器メーカーの見積照会への一次回答を5件並べると、在庫を確認し、標準価格を引き、標準納期を当てるという順序が5件とも同じでした。ところが特注仕様の価格交渉に向けた条件のすり合わせを並べると、値引きから入る件と納期から入る件があり、担当者によって見る順序が変わっています。同じ業務名で呼ばれていても、実物を5件並べるまでは、この違いが社内で共有されていませんでした。

落ちる条件は、件ごとに見る観点が変わること、担当者によって分岐の順序が違うことです。発生件数が多くても、この判断軸②で落ちる業務は初手に向きません。

判断軸③参照するデータがCRMの中に揃っていること

3つ目は「参照するデータがCRMの中に揃っていること」です。確認するのは、その業務で担当者が実際に開いている情報を1つずつ挙げ、CRMの中にあるか外にあるかで分ける作業になります。

ファイル共有フォルダ・メール・個人の手元のメモといったCRMの外に残るものがあれば、その業務は「データの整備が先に来る」と判定します。この判定は業務を否定するものではありません。着手の順番が後ろになるという、時点の判定です。

実装していて感じるのは、エージェントの回答が安定しない原因が、プロンプトの書き方より前の段階にあることが多いという点です。参照させる文書が探しにくい形のまま残っていると、どれだけ指示を書き直しても回答は安定しません。※参考記事はこちら

この産業機器メーカーでいえば、商談前の下調べがここで落ちます。落ちる条件は、参照先の情報がCRMの外にあること、そして同じ情報が複数の場所にあってどれが正しいかを決められないことの2つです。なお本記事はそろっているかどうかの判定までを扱い、整備の進め方には踏み込みません。

判断軸④失敗しても影響が社内にとどまること

4つ目の判断軸は、エージェントが間違えたときに、その影響が社内にとどまることです。確認の方法はまず、その業務の出力が顧客・取引先・社外文書のいずれかに直接届くかどうかで切ることになります。

ここで見落とされやすいのが、社外へ直接は届かない業務です。社内で止まったあとに誰が中身を確認するのかまで見ておかないと、確認する担当が決まっていない業務は、社内にとどまっていても影響の範囲が読めません。確認する担当者が不在の日にも回答が出る運用であれば、中身を見ないまま次の工程へ進む可能性があります。

見積照会への一次回答は、エージェントの回答がいったん営業担当へ渡り、その営業担当が顧客へ伝えます。間違いがあれば営業担当の段階で気づけるため、影響は社内で止まります。これに対して展示会リードへの初回連絡は、作った文面がそのまま見込み顧客へ届くため、確認の工程が入りません。

落ちる条件は、出力がそのまま社外へ出ること、出力を確認する担当が決まっていないことです。この判断軸④は自己申告がずれやすい箇所で、次章の3類型と突き合わせて初めて判定が確定します。

判断軸⑤効果を数字で測れる業務であること

最後の判断軸は、効果を数字で測れる業務であることです。確認の手順は2段階で、まず後述する3つの指標のうちどれを何の記録から取れるかを決め、そのうえで開始前の状態を1か月ぶん同じ形でそろえられるかを見ます。

開始前の状態をそろえられない業務は、効果が出ても出なくても判定できません。比較する相手がない状態で3ヶ月を過ごすことになるため、選定の段階で外しておくほうが確実です。

この産業機器メーカーの候補でいうと、返品・特別対応の例外処理は1件ごとに対応の内容が違い、作業の記録も担当者のメールにしか残っていませんでした。特注仕様の価格交渉も、条件を詰めた経緯が商談メモに散っており、開始前の状態を同じ形でそろえられません。見積照会への一次回答は、依頼と回答が同じ場所に残っているため、開始前の1か月ぶんを同じ形で取り出せます。

落ちる条件は、作業の記録が残っていないこと、比較の起点になる期間を取れないことです。以上が、Agentforceのユースケースを選ぶ5つの判断軸でした。

この5つで先ほどの候補6つを評価すると、次のような結果になります。

6つのうち残ったのは、見積照会への一次回答と、代理店からの技術的な問い合わせへの回答の2つです。落ちた4つも、この時点では初手に向かないという判定であり、データが整い、判断の手順を決めたあとに戻せる候補として扱います。

Agentforceの初手に向かない3つの業務

前章では5つの判断軸で候補を評価し、6つを2つまで絞りました。ところがこの2つのうち1つは、判断軸だけでは落ちきらない性質を持っています。5つの判断軸はAgentforceのユースケースの候補を絞るために使うものですが、軸の判定だけでは残ってしまう業務が存在します。そこでここでは、Agentforceの最初のユースケースには向かない業務を、3つの類型として整理します。

判断軸の○×がそろっていても、業務の性質が初手に向かない類型に当てはまる場合は、その業務を最初の1本にしません。

業務①年に数回しか発生しない例外処理

1つ目の類型は「年に数回しか発生しない例外処理」です。返品や特別対応のように、通常の手順に収まらない依頼を個別に判断する業務がこれに当たります。

この類型が初手に向かないのは、件数の少なさと手順のばらつきが同時に起きるからです。検証の期間内に数件しか発生しないため、うまくいったかどうかを数件の印象で判断することになります。しかもその数件は、それぞれ違う理由で例外になっているので、共通の処理として組めません。同じ返品でも、輸送中の破損、仕様の取り違え、納期の遅れによる取り消しでは、確認する相手も参照する記録も入れ替わります。

先ほどの候補では⑥返品・特別対応の例外処理が該当し、判断軸①の段階ですでに落ちています。担当者の負担としては確かに重い業務ですが、負担の重さと初手への向き不向きは別の話です。負担の重い業務から手をつけたくなるのは自然な発想でも、検証としての形にならない業務では、その負担が減ったことを社内へ示せません。

例外処理は、標準の業務をエージェントに任せて記録が貯まったあとに、改めて検討する順番になります。

業務②毎回異なる判断を求められる価格交渉

2つ目は、毎回異なる判断を求められる価格交渉です。特注仕様の条件づくりのように、値引きの範囲・納期・仕様の変更を組み合わせて決める業務が当てはまります。

価格交渉が初手に向かない理由は、判断の材料が社内の記録の外にあることです。相手の予算感、競合の状況、これまでの取引の経緯といった材料は、担当者の頭の中と、記録に残していない会話の中にあります。同じ製品でも初回の取引か継続の取引かで提示できる条件が変わり、その前提は商談の場で口頭のまま共有されています。

この産業機器メーカーの候補④も、判断軸②で落ちました。5件を並べたときに値引きから入る件と納期から入る件があったのは、案件ごとに交渉の前提が違うためです。エージェントに過去の条件を集めさせることはできても、どこまで譲るかの判断まで任せる形にはなりません。条件の一覧を出させたところで最後に決めるのは担当者になるため、任せられる範囲は結局のところ狭くなります。

価格交渉のような業務では、譲る条件の判断を任せず、判断に必要な材料を集める工程だけを切り出す考え方が有効です。この切り出し方は次章で扱います。

業務③人の確認を挟めない対外的な回答

3つ目の類型は「人の確認を挟めない対外的な回答」です。出力がそのまま社外の相手へ届き、途中で誰も内容を見ない業務がこれに当たります。

判断軸だけで見ると、この類型は見落とされやすい位置にあります。発生頻度も判断の定型度も高く、参照するデータもCRMの中にそろっており、5つの軸には○が並んでしまうからです。

実際、先ほどの候補⑤代理店からの技術的な問い合わせへの回答は、5つの判断軸では残りました。ところが仕様や互換性の回答は、代理店へそのまま返される前提で運用されています。社内の誰かが目を通す工程が入っていないため、間違いがあれば代理店を経由して顧客の設備に影響します。この時点で、候補⑤は初手から外れます。

判断軸④を「社内で完結する」と自己申告していた業務ほど、ここで判定が入れ替わります。残った候補が3つの類型で全部落ちた場合は、判断軸で△が付いた業務まで戻り、△になった理由を1つずつ確かめましょう。なお候補業務が少ない規模の場合は、ほか記事「中小企業のAgentforce導入ガイド｜向く理由・成果の出る業務・費用」で規模に応じた考え方を扱っています。

Agentforceに任せる範囲を決める4ステップ

ここまでで、6つの候補から見積照会への一次回答が1つ残りました。ここから決めるのは、その業務をまるごとエージェントに渡すのか、業務の一部だけを渡すのかという範囲の問題です。1つの業務をまるごと渡そうとすると、その中には必ず人が決めるべき判断が混ざってしまいます。そこでここでは、Agentforceに任せる範囲を決める手順を4つのステップに分けて整理します。

Agentforceのユースケースは、業務の中で発生する判断の単位まで分解してから、任せる範囲を割り当てます。

ステップ①対象の業務を工程に分ける

最初にやるのは、選んだ1つの業務を工程に分けることです。1つの業務に見えているものは、実際には複数の作業が順番に並んだ集合であり、その並びを書き出すところから始めます。

分ける粒度は、担当者が「ここで手が止まる」と言える単位が目安になります。細かく分けすぎると作業の一覧になってしまい、粗く分けると業務名の言い換えで終わります。1つの業務が3つから5つの工程に分かれる程度が、扱いやすい粒度になります。

見積照会への一次回答であれば、照会内容の読み取り、在庫と納期の確認、価格の提示、回答文の作成という4つの工程に分かれました。担当者に確認すると、時間がかかっているのは在庫と納期の確認で、価格の提示は短時間で終わっています。在庫と納期の確認に時間がかかっていたのは、基幹システムの画面と製品マスタを行き来しながら、型番ごとに条件を確かめていたためです。

工程に分けた時点で、業務をまるごと任せる必要がないことが見えてきます。どの工程が重いのかを先に把握しておくと、次のステップで書き出す判断の数も絞れます。

ステップ②工程ごとに発生する判断を書き出す

工程に分けたら、次はそれぞれの工程で誰が何を判断しているのかを書き出します。工程の名前は作業を表しますが、エージェントに任せられるかどうかを決めるのは、その中にある判断です。

この書き出しは、実際にその業務をしている現場の担当者と一緒に行います。工程の一覧は営業企画の側でも作れますが、どこで迷うのか、何を見て決めているのかは、毎日その作業をしている担当者にしか書けません。

先ほどの4工程で書き出すと、照会内容の読み取りでは「どの製品の問い合わせか」、在庫と納期の確認では「標準納期を適用してよいか」、価格の提示では「標準価格から外れるか」、回答文の作成では「営業担当へどう返すか」という判断が出てきました。「どの製品への照会か」という判断ひとつを取っても、型番が明記されている件と、用途だけが書かれている件では見る情報が変わります。参照する情報がどこにあるのかは、この段階でシステム部門の担当者にも確認しておきます。

書き出した判断が工程の数と同じくらいに収まっていれば、粒度としては適切です。判断が1工程に5つも6つも出てくる場合は、工程の分け方が粗いという合図になります。

ステップ③人が決める判断を先に確定する

判断を書き出したら、そのうち人が決めるものを先に確定させます。エージェントに任せるものから決めると、任せられそうなものが次々と増え、範囲が広がってしまうからです。

人が決める判断として残すのは、社外との条件に関わるもの、金額に例外が入るもの、そして責任の所在が問われるものです。この線引きは部門の責任者が決める部分であり、現場の担当者だけでは確定できません。口頭で共有したままにすると、検証の途中で担当者ごとの解釈が分かれてしまいます。

見積照会への一次回答では、価格の提示にある「標準価格から外れるか」を人が決める判断として残しました。標準価格の範囲に収まる案件は全体の多くを占めますが、外れる案件だけは営業担当が判断します。この1つを人の側に置いたことで、残りの3工程はエージェントへ渡せる形になりました。

金額に例外が入る判断を人の側へ残しておけば、エージェントが間違えたときの影響も、社内の確認で止まる範囲に収まります。ここは部門の責任者に確認を取ってから次へ進みましょう。

ステップ④残った判断をエージェントに割り当てる

人が決める判断を除いたら、残ったものをエージェントに割り当てます。割り当てるときは、その判断に必要な情報がどこにあるかを1つずつ書き添えておきます。情報の所在まで書いておくと、参照先を用意する工程で探し直す作業が減ります。

割り当ての結果は、次のような形で1枚に収めておくと、社内で共有しやすくなります。

この表を作ると、任せる範囲が業務の全体ではないと分かります。渡すのは4つの判断のうち3つです。営業企画の担当者が上長へ説明するときも、業務名だけを伝えるより、この粒度で示すほうが承認を得やすいでしょう。以上が、Agentforceに任せる範囲を決める4つのステップでした。

Agentforceを小さく始める3つの区切り方

前章では、任せる判断の範囲を1枚の表まで落としました。ここで戻ってくるのが、上長から言われた「まず小さく試せ」という指示です。対象の業務は1つに絞れていても、その業務を誰が、どれだけの期間使うのかまで決めなければ、Agentforceのスモールスタートは実行できる形になりません。そこでここでは、Agentforceのスモールスタートを、対象・利用者・期間という3つの区切り方として整理します。

小さく始めるとは、対象の業務・利用する人・検証の期間の3つを同時に限定することを指します。

区切り①対象を1つの業務に限定する

1つ目の区切り方は、対象を1つの業務に限定することです。5つの判断軸で残った業務が2つ以上ある場合でも、同時に走らせず、1つに絞ってから始めます。

1つに絞らずに複数の業務を同時に動かすと、出てきた結果がどちらの業務によるものかを切り分けられなくなります。うまくいかなかったときに、業務の選び方が悪かったのか、設定が合っていなかったのかも分かりません。判断軸で残った業務が2つあった場合も、件数の多いほうから始める、影響の小さいほうから始めるといった順番の理由を1つ決めておきます。

当社が支援の単位としているのも、1ユースケース×3ヶ月のスモールスタートプランという形です。この産業機器メーカーであれば、見積照会への一次回答の1本だけを対象にし、代理店向けの回答や商談前の下調べは、最初の1本が動いたあとの候補として残しておきます。

1つに絞ることは、ほかの候補を捨てることを意味しません。順番を決めるということであり、次の候補は最初の1本で得た記録をもとに選べるようになります。

区切り②利用者を1チームに限定する

2つ目は、使う人を1つのチームに限定することです。対象の業務を絞っても、営業部門の全員に配ってしまうと、問い合わせの対応に時間が取られ、検証の記録が残らなくなります。

限定する単位は、同じ業務を同じやり方でしている人の集まりが目安になります。拠点をまたぐと運用の細部が違うことがあるため、まずは1つの拠点、1つのチームから始めるほうが記録がそろいます。同じ拠点であっても、担当する製品群が違えば照会の内容も変わるため、最初は同じ製品群を担当している範囲に収めます。

見積照会への一次回答であれば、内勤で照会を受けている営業事務のチームが対象になります。利用する場面を普段の業務の中に置いておくことも大切で、担当者が毎日開いているチャットの画面から使える形にすると、別の画面を開く手間が減ります。この点については、ほか記事「Agentforce in Slackとは｜できること・導入手順とBox for Agentforceの位置づけ」で扱っています。

利用者を絞ると、担当者から出た意見を1件ずつ確認できます。人数を増やすのは、最初のチームで記録が取れてからで間に合います。

区切り③検証の期間を3ヶ月で区切る

3つ目の区切り方は、検証の期間を3ヶ月で区切ることです。期限を決めずに始めると、うまくいかない状態が続いても止める判断ができず、結論が出ないまま時間だけが過ぎていきます。

3ヶ月という長さには理由があります。1か月目は設定と調整に使われ、担当者が自分の判断で使い始めるのは2か月目からになり、比較できる期間を取るには最低でもこの長さが必要になるからです。

期間を区切るときは、その期間に発生する費用も先に見ておきます。エージェントの実行時にはアクションごとに消費されるクレジットがあり、検索やデータの取り込みで消費されるものも別にあります。消費量は使うモデルやプロンプトの種類でも変わるため、実行する前に条件を確認しておくほうが安全です。※参考記事はこちら

ライセンスやクレジットの費用の考え方については、ほか記事「Agentforce料金・ライセンス完全ガイド｜Flex Credits・従量課金・ユーザーライセンスの違いを解説【2026年最新】」をご確認ください。以上が、Agentforceを小さく始める3つの区切り方でした。

Agentforceのユースケースを測る3つの指標

前章で、1つの業務を1つのチームで3ヶ月という形まで絞り込みました。次に決めるのは、その3ヶ月で何を記録しておくのかという点です。何を記録するのかは検証を始めてからでは決められず、Agentforceのユースケースを選ぶ段階でそろえておかなければ間に合いません。そこでここでは、Agentforceのユースケースが測れる業務かどうかを判定するための3つの指標を整理します。

選定の段階で確認するのは、効果の大きさよりも先に、その効果を記録として残せる形になっているかどうかです。

指標①人が手を入れ直した割合

1つ目の指標は「人が手を入れ直した割合」です。エージェントが出した結果を担当者がそのまま使えたのか、それとも直してから使ったのかを、件ごとに残せるかどうかを確認します。

この指標を筆頭に置くのには理由があります。作業時間や利用の継続は、業務の繁閑や担当者の異動といった外側の事情でも動きますが、手を入れ直したかどうかは、エージェントの出力に対する担当者の判定だからです。使い続けているのに毎回直しているという状態も、この記録があれば見えてきます。

記録の形として大切なのは、直した回数や直した文字数まで数えないことです。直しが発生した件かどうかという二択で残せれば、選定の判定としては足ります。見積照会への一次回答であれば、営業担当が回答をそのまま顧客へ転送したか、書き換えてから送ったかの区別が残せるかを確認します。

判定としては、直しの有無を誰がどこに残すのかを決められない業務は、測れない業務として扱います。逆にいえば、既存の記録の中にその区別を残せる場所が1つでもあれば、この指標は選定の段階で成立します。判定の場所を決めるのは、現場の担当者と、その記録を見る営業企画の両方です。

指標②その業務にかかっていた作業時間

2つ目に確認するのは、その業務にかかっていた作業時間です。ここで見るのは削減できる量の見込みではありません。開始前の所要時間を1か月ぶん、同じ形でそろえられるかどうかです。

同じ形でそろえるというのは、測り方を1つに決めるという意味です。担当者が記録した所要時間と、システムに残る操作の時刻を混ぜて集計すると、開始後の数字と比べられなくなります。記録を取る担当者を1人に固定するか、システムに残る時刻だけを使うか、どちらかへ寄せておきましょう。

見積照会への一次回答であれば、照会を受け付けた時刻と、回答を返した時刻が同じ場所に残っていました。この2つの差を1か月ぶん取り出せるため、開始前の状態をそろえられます。一方で商談前の下調べは、担当者が空き時間に少しずつ進めているため、開始と終了の時刻が残っていません。所要時間が担当者の記憶にしか残っていない業務は、開始前の状態を同じ形でそろえられない業務に当たります。

開始前の所要時間をそろえられない業務は、選定の時点で外します。ここで判定するのは測れるかどうかまでで、どれだけ短縮できたかの計算は検証を始めたあとの話になります。

指標③現場が使い続けている割合

3つ目の指標は、担当者がその業務の中でエージェントを使い続けているかどうかです。判定するのは、業務の流れの中でエージェントを開く場面が決まっているか、という点になります。

開く場面が決まっていない業務では、使ったかどうかの記録が担当者の意思に左右されます。思い出したときだけ使う状態になると、使われなかった週の意味を読み取れません。使う場面を決めるというのは、業務の手順書に「ここでエージェントに投げる」と書ける状態にすることです。

見積照会への一次回答では、照会のメールを受け取った時点でエージェントに投げるという場面が決まっています。この場面が固定されていれば、照会の件数とエージェントの利用件数を並べるだけで、使い続けているかを確認できます。特注仕様の価格交渉のように、担当者が必要だと感じたときだけ使う業務では、この並べ方ができません。

業務の流れの中に使う場面を置けない業務は、選定の段階では見送ります。以上が、Agentforceのユースケースが測れる業務かどうかを判定する3つの指標でした。

Agentforceで作るエージェントの3つの型

ここまでは、どの業務を、どの単位で、何を記録しながら試すのかを決めてきました。ここで初めて、選んだ業務をどの型で作るのかという話に移ります。そこでここでは、Agentforceで作るエージェントの型を3つに分けて整理します。

エージェントの型は、業務と任せる判断が決まったあとに当てはめるものであり、型から業務を逆算しません。

型①問い合わせ対応を担うサービス系

1つ目は、問い合わせ対応を担うサービス系の型です。顧客や社内から届いた問い合わせに対して、あらかじめ決めた参照先をもとに一次回答を返す形になります。

この型を選ぶ場合、自社で用意するのは回答の参照先と、答えてよい範囲の線引きです。範囲を決めずに公開すると、想定していない質問へも回答してしまいます。答えられない内容が届いたときに、人へ引き継ぐ条件もあわせて決めておきます。

型の中身と、チャットボットとの違いについては、ほか記事「Agentforce Service Agentとは？チャットボットとの違いと導入設計を解説【2026年最新】」で詳しく解説しています。

型②営業のリード対応を担う営業系

2つ目は、営業のリード対応を担う営業系の型です。問い合わせや資料請求で入ってきたリードへの連絡と、商談の準備にあたる作業を担います。

用意するのは、どのリードを対象にするかの条件と、連絡する文面の型です。対象の条件が広いまま動かすと、営業担当が確認する件数が増えてしまいます。リードの数が多い場合は、条件を狭めた状態から始めて、あとから広げる進め方が確実です。

営業系の型で何ができるかは、ほか記事「Agentforce for Sales完全ガイド｜SDR・Sales Coachの使い方と営業活用事例【2026年最新】」をご参照ください。

型③標準の型に当てはまらない業務向け

3つ目は、標準の型に当てはまらない業務に向けて、自社で組み立てる形です。見積照会への一次回答のように、社内の担当者へ向けて回答を返す業務はここに入ります。

この型では、前章までに作った工程と判断の割り当てが、そのまま設計の材料になります。逆にその割り当てがないまま組み始めると、どこまで任せるのかが決まりません。回答を受け取るのが自社の担当者であれば、確認の工程を業務の中に組み込みやすくなります。

組み立てに使う機能の全体像は、ほか記事「Agentforceの機能一覧｜360・Coworker・Voiceまで主要機能を整理」で確認できます。

Agentforceの業務設計でつまずく3つの箇所

前章では、選んだ業務を当てはめる型まで進みました。ここからは、実際に組み立てる段階で手が止まる箇所を先にお伝えします。実装していて感じるのは、手が止まるのは操作の場面ではありません。その手前の業務設計で決めていなかったことに気づく場面です。そこでここでは、Agentforceの業務設計でつまずきやすい3つの箇所を整理します。

組み立ての段階で手が止まる原因の多くは、設定の難しさよりも、業務設計で決め残していた項目にあります。

箇所①必要なデータがCRMの外に散らばっている

1つ目は、必要なデータがCRMの外に散らばっていて、参照させる前の工程が必要になる箇所です。判断軸③で判定していたつもりでも、実際に組み始めると細かい抜けが出てきます。

面談が終わったあとに見込み顧客へ要約メールを送るというユースケースを組んだときも、面談で使ったスライドや資料のファイルを対象のレコードに関連づける工程が先に必要でした。ファイルが手元の共有フォルダにあるだけでは、エージェントから読み取れません。あわせて、この構成ではメールの送信をエージェント側から実行できず、レコード画面の送信機能へ本文を渡す形になりました。※参考記事はこちら

この産業機器メーカーで見積照会への一次回答を組む場合も、在庫の情報が基幹システムにあるなら、参照できる形にする工程が先に入ります。基幹システムの情報をどの単位で参照させるかは、システム部門と一緒に決める項目になります。ここを検証の3ヶ月に含めるのか、その前に終わらせておくのかを、開始前に決めておきましょう。

箇所②似ていると判定する基準が決まっていない

2つ目につまずくのは、「似ている」という判定の基準が決まっていない箇所です。過去の似た案件を探すという指示は、担当者の間では通じても、そのままでは組めません。

過去の類似案件を抽出するユースケースを構築したときは、類似度を測る項目として「業種」「従業員数」「事業概要」「面談・商談メモ」の4つを先に定義しました。ただ、4つを挙げるだけでは基準になりません。そのうち事業概要と面談商談メモの中にある課題の文脈を最優先とし、業種と従業員数はその次に置くという優先順位まで決めて、初めて判定の指示として成立します。優先順位を決めないまま指示を書くと、業種と従業員数だけが一致した案件が上位に並び、担当者が本当に見たかった案件は下に埋もれてしまいます。※参考記事はこちら

見積照会でも、過去の同種の照会を参照させるなら、型番の一致を優先するのか、数量の近さを優先するのかを決めることになります。この優先順位は現場の担当者しか決められないため、設計の段階で確認しておく項目です。

箇所③取り込んだデータの対応づけが自動で終わらない

3つ目は、取り込んだデータと参照する項目の対応づけが、自動では終わらない箇所です。データを用意すれば、そのまま使える状態になると思っていると、ここで作業が増えます。

同じユースケースを構築したとき、バンドルを選ばずにオブジェクト単位で選択していたため、どの項目にも対応づけがされていない状態から作業を始めることになりました。あらかじめいくつかの項目が対応づけられている選択肢もあるので、どちらを選ぶかで作業量が変わってきます。対応づけは参照させたい項目の数だけ発生するため、項目が10あれば10回、どの情報をどこに当てるのかを1つずつ指定することになります。※参考記事はこちら

この工程は、検証の期間の見積もりから抜け落ちやすい部分です。作業が難しいわけではありませんが、まとまった時間が必要になるため、設定を始める日から逆算して確保しておきます。また、対応づけを終えたあとに参照する項目を増やすと、同じ作業がもう一度発生します。3ヶ月の区切りを決めるときは、対応づけの作業を1か月目の中に見込んでおくほうが、後半の検証に時間を残せます。

Agentforceの業務選定を検証する3つの問い

前章までで、選定から実装の手前までを一通り並べてきました。ここで一度、自社の選定が成立しているかどうかを確認しておきます。Agentforceのユースケース選定は手順を追うだけでは終わらず、自社の結論が社内の記録で裏づけられているかどうかを別に確かめる必要があるからです。そこでここでは、Agentforceの業務選定が妥当かを自分で検証するための3つの問いを整理します。

自社の選定が妥当かどうかは、3つの問いに社内の記録で答えられるかどうかで確認できます。

問い①その業務は本当に繰り返し起きているか

1つ目の問いは、選んだ業務が本当に繰り返し起きているかどうかです。ここで答える材料になるのは、担当者の実感より、直近3か月の記録です。

記録を見ると、毎日起きていると思っていた業務が、実は特定の担当者のところにだけ集中していたと分かることがあります。逆に、それほど多くないと思われていた業務のほうが、部門全体では件数が多いという場合もあります。

見積照会への一次回答であれば、照会のメールが何件届いたかを月ごとに並べます。3か月とも同じくらいの件数が並んでいれば、この問いには答えられている状態です。特定の月だけ件数が増えている場合は、その月に何があったのかを確認しておきます。あわせて、依頼を受けた件数と実際に対応した件数を分けて数えます。この2つが大きく離れている業務は、対応しきれていない依頼が積み上がっている可能性があります。

この問いに記録で答えられないときは、選定をやり直すというより、記録の残し方を先に決める段階だと考えます。

問い②必要なデータに手が届く場所にあるか

2つ目は、その業務で参照する情報が、エージェントから参照できる場所にあるかどうかです。判断軸③で一度判定していますが、任せる判断が確定したあとに、もう一度この問いを通します。

同じ問いを二度置くのは、任せる判断が決まった段階で、必要な情報の範囲が変わっているからです。工程のうち3つを任せると決めたなら、参照するのはその3工程で使う情報だけになります。

見積照会の例でいえば、価格の提示を人の判断として残したことで、値引きの履歴を参照させる必要がなくなりました。参照する対象は製品マスタ、在庫、標準価格表、標準納期の4つに絞られています。この4つがどこにあるかを、システム部門の担当者と一緒に確認します。確認するときは、その情報がどの部門の管理下にあるのかもあわせて記録します。管理する部門が分かれている情報は、参照できる形にするまでの調整に時間がかかるためです。

参照する対象を絞り込めたかどうかが、この問いの答えになります。範囲が最初と変わっていない場合は、ステップ③に戻って人が決める判断を洗い出し直しましょう。

問い③成果を判定する担当者が決まっているか

3つ目の問いは、3ヶ月後にその結果を判定する担当者が決まっているかどうかです。ここで確認するのは、判定する人の名前が挙がっている状態になっているか、という一点になります。

判定する担当者が決まっていないまま始めると、記録は残っても、それを見て続けるかどうかを決める人がいません。報告の場に関係者が集まっても、判断の権限がある人が不在では結論を出せません。なお、判定する担当者を決めることと、運用を担当する人を決めることは別の話であり、ここで確認するのは前者だけです。

この産業機器メーカーであれば、営業事務のチームの責任者と、営業企画の担当者の2名が判定に加わります。判定に使う記録は、指標①から③で決めた3つです。判定の日を検証の開始時点で決めておくと、記録の取り方も逆算できます。

3つの問いのすべてに社内の記録で答えられれば、その選定は成立しています。どれか1つでも答えられない場合は、その項目に戻って埋めてから検証に入りましょう。

Agentforceの業務設計を相談する3つの目安

前章の3つの問いに答えられていれば、自社だけで進めて問題ありません。候補が1つに絞れていて、参照するデータの所在が分かっていて、成果を判定する担当者が決まっている状態であれば、外部の支援がなくても検証まで進められます。一方で、その3つのどれかが埋まらないまま時間だけが過ぎている場合は、Agentforceの業務設計を外部と一緒に進める判断もあります。そこでここでは、外部へ相談する判断の目安を3つに分けて整理します。

外部への相談が必要になるのは、候補を絞る基準を社内で作れないときです。

目安①候補業務が5つ以上あって絞り込めない

1つ目の目安は、候補として挙がった業務が5つ以上残っていて、社内の議論では絞り込めない状態です。この状態は、情報が足りないというより、比べるための項目を作れていないことを示しています。

候補が多いこと自体は問題ではありません。判断軸を当てはめれば、多くの候補はどこかの軸で落ちるからです。この判断軸を社内だけで作ろうとすると、それぞれの部門が自部門の業務を推すため、比べる項目のない話し合いは平行線になりやすいものです。

先ほどの産業機器メーカーでも、6つの候補は5つの判断軸を通すと2つまで減りました。当社が支援する場合も、1ユースケース×3ヶ月のスモールスタートプランという単位で、まず1本を決めるところから入ります。

候補が5つ以上残ったまま2か月以上が経っているなら、社内の議論を続けるより、判断の項目を外から持ち込むほうが早いでしょう。決まらない状態が続くほど、確保した予算だけが手元に残り、着手の時期が後ろへずれていきます。

目安②業務の全体像を書ける担当が社内にいない

2つ目は、対象の業務を工程と判断に分けて書ける担当者が、社内に見当たらない状態です。部門ごとの作業は分かっていても、それを1枚に並べて判断の所在まで書ける人は、意外と限られます。

この作業には、業務側の理解とAgentforceの仕組みの理解が両方必要になります。片方だけでは、工程の一覧か機能の一覧のどちらかで止まってしまいます。工程と判断に分けて書く作業は、業務の担当者へのヒアリングと、参照するデータの所在の確認を同時に進めることになるためです。通常業務との兼任で進めると、書き上がるまでに数か月かかることもあります。

社内の担当者に必要な知識を身につけてもらう方向で考える場合は、その水準を測る目安として資格の学習範囲が参考になります。詳しくは、ほか記事「【2026年最新】Agentforceスペシャリスト資格の試験概要や勉強法」で扱っています。

社内で担当を決めるまでの間だけ外部と組む、という形も選べます。最初の1本を一緒に設計し、2本目からは社内で進める進め方です。

目安③前回のPoCが結論を出さずに終わった

3つ目の目安は、前回のPoCが結論を出さずに終わっている場合です。同じ進め方でもう一度始めると、同じ止まり方をする可能性があります。

前回の検証を振り返るときに確認したいのは、対象に選んだ業務が5つの判断軸のどれで落ちる業務だったのか、という点です。ここが特定できていれば、次の候補は自社でも選べます。特定できないまま次に進むと、業務の選び方を見直さずに、設定の作り込みへ原因を求めてしまいます。前回の記録が残っていない場合は、当時の関係者に対象の業務と止まった段階だけでも確認しておきましょう。

外部へ相談する場合の会社の選び方は、ほか記事「Agentforce導入支援会社のおすすめ8選｜失敗しない選び方と7つの見極め方【2026年最新】」で整理しています。

当社では、ソリューション営業の業務プロセスに合わせたAgentforceの導入・定着支援を行っています。どの業務から始めるかの整理からご相談いただけますので、詳しくはAgentforce導入定着支援サービスのページをご覧ください。

【一問一答】Agentforceのユースケースに関するよくある質問

ここまで、Agentforceのユースケース選定を、状況の整理から判断軸、任せる範囲の分解、相談の目安まで並べてきました。ここで扱えなかった細かい前提のうち、選定を進める中で実際に出てくるものを最後にまとめます。そこでここでは、Agentforceのユースケースに関するよくある質問へ順番に答えていきます。

Agentforceのユースケース選定に関する疑問は、業務の性質に置き換えて考えると答えが出せます。

質問①Agentforceのユースケースは何から選べばよいか

社内の候補業務を挙げたうえで、発生頻度・判断の定型度・データの有無・失敗時の影響範囲・測定可能性の5つで評価し、残ったものから選びます。上長が推す業務と自分が推す業務が違う場合も、この5つを当てはめれば、どの項目で判断が分かれているのかを言葉にできます。

質問②Agentforceのユースケースはいくつから始めるべきか

1つです。複数を同時に動かすと、結果がどの業務によるものかを切り分けられなくなります。候補が2つ残った場合も、順番を決めて1本目を先に進め、その記録をもとに2本目を選ぶ進め方が確実でしょう。

質問③Agentforceのユースケース選定に必要なデータは何か

対象の業務で担当者が実際に開いている情報が、そのまま必要なデータになります。選定の段階で確認するのは、それらがCRMの中にあるか外にあるかという所在だけです。外にあるものが含まれていれば、その業務は整備を終えてから着手する順番へ回します。

質問④Agentforceのユースケースは他社事例をそのまま使えるか

そのままの形では使えませんが、読み替えれば十分に参考になります。読み替えるときに見るのは、業種や企業規模より、その事例の業務が持っていた性質です。発生頻度・判断の定型度・データの有無・失敗時の影響範囲・測定可能性の5つに置き換えれば、自社の候補業務と比べられます。

質問⑤Agentforceのユースケース選定にかかる期間はどれくらいか

候補業務の洗い出しと5つの判断軸による評価は、記録がそろっていれば短期間で終わります。時間がかかるのは、直近3か月の件数や作業の記録を取り出す作業のほうです。記録が残っていない業務が多い場合は、記録の残し方を決める期間を別に見込んでおきましょう。

Agentforceのユースケースは任せる判断の単位まで分解して選ぶ

Agentforceのユースケースは、機能の一覧から選ぶものではありません。自社の業務を5つの判断軸で評価し、その業務の中で発生する判断の単位まで分解してから決めるものです。本記事では、候補が並んだまま決められない状況から、判断軸による絞り込み、初手に向かない業務の見分け方、任せる範囲の分解、小さく始める区切り方、測れるかどうかの判定までを一連の流れとして整理してきました。

最初の1本を決めるときに立ち返る点は、次の3つです。

1. 5つの判断軸で評価する・・・1つの基準だけでは候補業務の順番が決まりません
2. 判断の単位で割り当てる・・・人が決める判断を先に確定します
3. 測れる形かどうかを見る・・・開始前の記録をそろえられるかで判定します

なお本記事では費用の金額には触れていません。ライセンスやクレジットの考え方はAgentforce料金・ライセンス完全ガイドで、機能の全体像はAgentforceの機能一覧で確認してもらえると、選定の判断がしやすくなります。

どの業務から始めるかを決める段階でつまずいている場合は、BtoBマーケティング無料相談もご利用いただけます。本記事で整理した判断軸を、ぜひ自社の候補業務に当てはめてみてください。少しでもお役に立てれば幸いです。