Microsoftチケットシステム:2026年の5つの現実的な選択肢

Microsoftにはチケットシステムがありますか?

その名前で購入できる製品としては、ありません。

最も近いのはDynamics 365 Customer Serviceで、Microsoftは「AIエージェントを使って問題を迅速に解決できるようサービス担当者を支援する」というラインで位置づけています。これはDynamics 365とPower Platformのスタックの上に乗るケース管理アプリケーションで、エンタープライズソフトウェアの販売方法で販売されています。有料プランのすべてで唯一のコールトゥアクションはお問い合わせです。営業ラインは太平洋時間の月曜から金曜、午前6時から午後3時まで対応しています。

このフレーミングは聞こえるより重要です。チケットシステムはワークフローを備えたキューです。CRMのケースは顧客に紐づいたレコードで、この2つは十分に重なるため、一部の購入者は方向を決めずにCRMチケットシステムを探し始めます。しかし購入の動きと価格はまったく似ておらず、セットアップの手間も同様で、そのために多くのIT部門が結局は自分たちで何かを構築することになります。

2026年にMicrosoftのページを読む前に知っておくべき名称変更がもう一つあります。Microsoftは人間の呼び方を変えました。 Customer Serviceのページ全体で、チケットに回答する人は今「サービス担当者(service representative)」または「service rep」と呼ばれ、「エージェント」という言葉はAIに割り当て直されました。製品ページの専用セクションは文字通りSERVICE AGENTSと見出しがつき、「エージェント型サービス」を説明しています。Microsoftのドキュメントがエージェントがケースを処理したと言うとき、それは人間が処理したことを意味しません。

5つのルートの比較

それぞれを詳しく見る前に、正直な比較を示します。以下の価格はすべて、2026年7月31日にMicrosoft自身の価格ページから取得した、米国のリスト価格、年払いのユーザーあたり月額です。

この表から2つのことが目立ちます。レポートは、Microsoft自身の50ドルの製品を含め、各ルートの安価な側で欠けています。そしてキューを本当にキューにするものであるチケットIDは、ルート3まで適切には存在しません。キューにAIを乗せることが比較の本当の理由であれば、チケットシステム向けAIについての私のより広い考察もこれと合わせて読む価値があります。

ルート1:共有メールボックス

Microsoftのサポートキューのほぼすべてがここから始まり、しばらくの間はうまく機能します。Outlookの共有メールボックスは、すでに持っているMicrosoft 365ライセンスに加えて何もかかりません。誰もが見ることができ、誰も新しいことを学ぶ必要はありません。数人のエージェント以上には決して成長しない小規模チーム向けチケットシステムにとっては、これが答えのすべてになることも多いです。

これは1つのことで破綻します。チケットIDがないので、状態がありません。メールが処理中かどうかを判断できません。火曜日に届いたスレッドが先週のものと同じ問題かどうか判断できません。そして最終的に2人のエージェントが1分以内に同じ顧客に返信することになります。人々が考案するあらゆる回避策(色分けカテゴリー、「対応済み」フォルダ、件名での命名規則)は、ステータスフィールドの手作りの再実装です。

閾値はチームが予想するより低いです。2人以上が同じメールボックスを扱うようになるか、誰かが「返信にどのくらいかかっているか?」と尋ねるようになった時点で、メールボックスはもう十分ではなくなっています。私は共有インボックス対チケットシステムのトレードオフについてより詳しい比較を書いており、キューを失わずにメールを窓口として残したいチーム向けのメールヘルプデスクソフトウェアについても別に見ています。

結論: 出発点としては問題ありませんが、これを中心に構築してはいけません。誰が何を扱うかについてルールを書き始めた時点で、すでにそれを超えています。

ルート2:Power Automateを乗せたSharePointリスト

これは典型的な自前構築で、私が最も聞かれるものです。SharePointリストがチケットを保持します。Power Automateフローが新しい項目を検知して通知を発火させ、Teamsタブがリストを表示します。3つすべてに既に料金を払っているため無料に見えますが、規模が大きくなってもそれが成り立つと決めつける前に、専用デスクと比較してSharePointの価格を確認しておく価値があります。

これは現実的な選択肢です。しかし、Microsoftのスタック全体で最も正確に文書化された上限も抱えており、ほとんど誰も構築前にその上限を確認しません。

5,000項目の壁

SharePointのList View Thresholdは5,000です。Microsoft自身の言葉によれば、「この制限を超える操作はブロックされます」。理由はSQLの行ロックです。約5,000件のロックされた行を超えると、SQL Serverはテーブル全体をロックするほうが効率的だと判断するため、Microsoftは代わりにクエリをブロックします。

ほとんどの記事で見落とされている3つの詳細です。

• 警告は5,000ではなく3,000で発生します。 実際に何かが破綻するかなり前に、リスト設定ページでそれを目にします。
• その数値は固定ではありません。 Microsoftはこれを直接的にヘッジしています。「実際の数値は必ずしも5,000ではなく、サイト、データベース内のアクティビティ量、サイトの構成によって変動する可能性があります。」
• 上げることはできません。 監査人や管理者向けの20,000項目のオーバーライドはSharePoint Serverの機能です。SharePoint Onlineでは、この制限は「変更できません」。

リスト自体は3,000万項目を保持できます。これは、SharePointが問題なくスケールすると人々が言うときに引用する数字です。しかし、キューとは実際にはリスト上のビューであり、ビューはリスト自体よりもはるかに先に破綻します。月に200件のチケットをクローズするチームは、15か月以内に警告帯に入り、2年以内にブロック帯に入ります。

それを動かすフローは最悪のティアにある

Power Automateはすべてのアカウントをパフォーマンスプロファイルに分類します。すでに所有しているMicrosoft 365ライセンスの上に構築するチームは、Microsoftが公開するすべての表の中で最悪の行であるLowに分類されます。Lowでは:

• 24時間あたり10,000件のPower Platformリクエストで、Mediumの200,000件、Highの500,000件に対してです。
• Apply to eachは5,000件の配列項目で上限に達しますが、他のすべてのプロファイルでは100,000件です。ページネーションも5,000で上限に達するため、SharePointの閾値を打ち消すのではなく、それに積み重なります。
• 最小の再発間隔は60秒なので、ポーリングする「新規チケット」フローは、何かが発火するまでに最悪の場合フルで1分の検知遅延があります。
• SharePointコネクタ自体は接続あたり60秒間に600 APIコールでスロットルされます。

そして静かな殺し屋は、MicrosoftのPower Automateの制限ドキュメントによれば、制限を14日間超え続けたフローについて「システムはそれをオフにします」ということです。エラーのあるフローも14日後にオフになります。ボリュームの急増から2週間後にルーティングが静かに停止するキューは、非常に悪い火曜日です。

もう一つのライセンストラップがここにあります。通常のMicrosoft 365ライセンスは、有料のPower Platform座席が得る40,000件ではなく、ユーザーあたり24時間で6,000件のPower Platformリクエストしか含みません。すべてのコネクタ呼び出しが1リクエストとして数えられ、すべてのHTTPアクションも同様で、変数の初期化から単純なcomposeまで、すべての組み込みアクションも同様です。Microsoftはリクエスト制限のドキュメントで明確に述べています。「成功したアクションも失敗したアクションも、これらの制限にカウントされます。再試行やページネーションからのリクエストもカウントされます。」

結論: 予測可能なボリュームで成長計画のない小規模な社内キューには良い選択です。顧客対応のキューをこれに乗せてはいけません。そしてリストが3,000行を超える日のためにカレンダーのリマインダーを設定してください。

ルート3:Dataverse上のPower Apps

SharePointの構築が始まりの場所であれば、これはそれが軋み始めたときにエスカレーションする先です。Dataverse上のモデル駆動型Power Appは、本物のデータモデル、本物のリレーション、本物のチケットID、そして自分で制御するUIを与えてくれます。

問題はライセンスで、Microsoftはできるだけ明確にそれを述べています。「アプリの構築には課金されませんが、その使用には有料ライセンスが必要です。」 無料のPower Apps Developer Planは、3つの開発者環境での構築とテストをカバーし、月間750の自動化フローという上限があります。本番環境は別のSKUです。

つまり実際の下限は、1件のチケットにも回答する前に、年間契約でエージェントあたり月35ドルです。10人のエージェントで月350ドル、または年間4,200ドルとなり、それでも自分で構築し維持しなければならないソフトウェアのためにです。

実際には2つの注釈が痛手になります。まず、Dataverseの権限はユーザーあたりではなくテナントレベルでプールされます。Premium座席あたり250MBのデータベースと2GBのファイルなので、10人のエージェントは2.5GBのデータベースをプールすることになります。添付ファイルを持つチケットシステムはファイルプールよりずっと先にデータベースプールを使い切ってしまい、それを拡張すると月間GBあたり40ドルかかります。次に、Power AppsにおけるMicrosoftのエージェント機能は「モデル駆動型アプリのみで利用可能」であり、キューをキャンバスアプリとして構築すると、そのレイヤーは単純に存在しません。

誰も警告してくれない委任問題

Dataverseの代わりにSharePoint上に構築する場合、Power Appsの委任がアプリにできることを静かに変えてしまいます。誰もが引っかかるもの:SharePointのID フィールドはPower Appsでは数値のように見えますが、その下ではテキストであるため、SharePointはID フィールドの委任について「等しい('=')演算のみをサポート」しています。リレーショナル演算子は単に機能しません。「4,000を超えるIDを持つすべてのチケットを表示」というのは委任可能なクエリではありません。

Notは決して委任されません。14個のシステムフィールドは決して委任されません。UpdateIfとRemoveIfは実際にはほとんど委任されず、「ローカルで機能し、500/2000レコードの制限まで委任をシミュレートします」。それぞれ単独では乗り越えられます。まとめると、これらが自前のMicrosoftキューが1日目には速く、400日目には遅いという評判を持つ理由です。

結論: ワークフローが本当に独特で、社内に開発者がいる場合には正しい構築です。要件が「チケット、ステータス、割り当て、SLA」であれば、パッケージ製品としてすでに存在する社内ヘルプデスクを数か月かけて再構築することになりかねません。多くのパッケージ化された社内デスクがまさにこの形をそのまま標準でカバーしており、ライセンスコストが反対理由であれば、自分でホストできるオープンソースのチケットシステムもあります。Microsoft自身も、社員のオンボーディングや資産のチェックアウトと並んで、すぐに使えるPower Appsのテンプレートの1つとして**「ヘルプデスク管理」**を挙げることでそのようにフレーミングしています。

ルート4:Teams内のCopilot Studioエージェント

これはチケットシステムというよりデフレクションレイヤーであり、分けて考える価値があります。「Teamsでチケットシステムを構築した」というプロジェクトの多くは、実際にはこれです。

Copilot Studioは、エージェントを構築するためのMicrosoftのローコードプラットフォームです。Power Virtual Agentsを吸収し、Teams、SharePoint、Microsoft 365 Copilotに公開し、1,400を超えるコネクタを通じてリーチします。Microsoftはフォーチュン500の90%がそれを使用していると主張しています。G2では156件のレビューで5点中4.4点の評価です。

繰り返される質問のIT キュー(「VPNをリセットする方法」「経費規定はどこにある」)には、SharePointとConfluenceを読み取るTeams内のエージェントは、スタックの正当に良い使い方であり、Microsoft Teams内のAIがうまく行う仕事そのものの形です。基本的にはキューの前に座るTeams IT サポートボットです。得られないものは、キュー、ステータス、割り当て、そしてそれが答えられなかったことについてのレポートです。

コスト構造は、コミットする前に理解すべきものであり、独自のセクションに値します。

2つ目のメーター:Copilot Credits

ここに、Microsoftを座席コストだけで価格算出した人々を驚かせる部分があります。座席ライセンスにはAIは含まれていません。 Customer Service ProfessionalとEnterpriseでは、Microsoftが名前を付けた4つのサービスエージェントすべて - ケース管理エージェント、顧客ナレッジ管理エージェント、顧客インテントエージェント、品質評価エージェント - がすべて、Microsoft自身のプラン比較で「Copilot Creditsが必要(別売)」とマークされており、それを軸に構築しているチケットデフレクション計画と一緒に読む価値があります。

クレジットはCopilot Studioを通じて月25,000 Copilot Creditsあたり200ドル、年払いで購入します。これはリスト価格でクレジットあたり0.008ドルに相当しますが、Microsoft自身がクレジットあたりのレートを表示することはありません。両方のクレジットプランは、それぞれのカードに印刷された同じ前提条件を持っています。「エージェントを使用するにはAzureサブスクリプションが必要です。」

得られない数字が、あなたが必要とする数字です。Microsoft自身の注釈は、エージェントによってアクションや応答が完了するたびに、Power Automateの価格ページによると「具体的な使用状況に応じて、変動する数のCopilot Creditsが課金されます」と述べています。公開されているレートは、クラシックな回答の1クレジットからプレミアムな生成応答の100クレジットまでの範囲です。テナントグラフのグラウンディングに10を追加し、推論モデルが関与する場合はさらに別のプレミアムトークンメーターが上乗せされます。どこにも解決済みチケットあたりのクレジット数という数字はなく、クレジットパックあたりのコストは計算できても、チケットあたりのコストは決して計算できません - これはまさに、チケットあたりの価格設定をするAIチケットシステムが埋めるように作られたギャップです。

195ドルのPremiumティアはそれらのエージェントについて「含まれる容量」をリストしていますが、注釈6はそれを「基本Copilot Credit容量」と限定し、数量は公開されていません。その数字はダウンロード可能なライセンスガイドにのみ存在します。

これはどれも理論上のリスクではありません。2026年6月、r/copilotstudioの投稿者は、何かがループに入ったときに予測不能なメーターが何をするかを正確に描写しました。

「その後、devからprodに1つのエージェントをデプロイしました。それだけです - 単一のエージェントです。今日Azureサブスクリプションを確認したところ、約47,000ドルの請求がありました。」

Woke up to a $47K bill after deploying ONE Copilot Studio agent, Reddit

そのメカニズムは返信の中に現れており、それは何かをオンにする前に理解しておく価値がある部分です。

「CopilotのAzureサブスクリプションを使ったPAYGの予算は、アラートの目的だけです。それにはハードなサービス停止はありません…受信メールによってトリガーされるエージェントフローがあり、誤って自分自身の受信箱にメールを送ることで自らループに陥ってしまいました。」

NikoThe1337, 同じスレッドで, Reddit

Azureの従量課金予算はアラートを出しますが、停止はしません。 自分自身の受信箱に返信できるメールトリガーのフローはループであり、誰かが気づくまでメーターは回り続けます。

ここでは公平でありたいと思います。これは無能さではなく、本物のモデリング問題です。使用状況は本当に変動し、チケットあたりの固定料金は、顧客の代わりにベンダーがその変動を吸収することを意味します。それでもeesel自身の価格調査は、その反対側に強く着地しました。私たちは架空の単位を試し、それを撤回しました。なぜなら「クレジット」という言葉が顧客に計算を強いたからです - 私たちが繰り返し聞いた反応は「待って、クレジットって何?」のようなものでした。チケットとチャットセッションは、サポートマネージャーがすでに考える単位です。予算を守らなければならない人が請求書を予測できないとき、ロールアウトは調達で停滞し、どんなモデルの品質もそれを救うことはできません。

ルート5:Dynamics 365 Customer Service

本当の製品です。パーツの組み合わせではなく、Microsoftに本物のITSMチケットシステムを売ってもらいたいなら、これがそれです。

ケースとは実際に何か

Dynamicsのケースは、ほとんどのヘルプデスクチケットよりも独自の思想が強いです。それを中心にワークフローを設計する前に、制約を知っておく価値があります。

• 3つのステータスが標準で提供されます: アクティブ、解決済み、キャンセル済み。アクティブには名前付きサブステータス(進行中、保留中、詳細待ち、調査中)があります。
• ケースのマージは10件が上限です。 デフォルトでは一度に最大10件のケースをマージできて、マージされたケースはマージ済みというステータス理由でキャンセル済みに切り替わります。
• 階層は正確に2レベルです。 子ケースは子ケースを持つことができず、親ケースは他のケースの子にはなれません。あなたのエスカレーションモデルが3階層のネストを持つ場合、それには合いません。
• SLAの移行には上限があります。 1,000件を超えるSLAを移動すると移行前チェックが失敗する可能性があり、関連エンティティのSLA条件は1レベルに限定されます。

これらはどれも決定的な障害ではありません。すべて、9週目ではなく1週目に見つけたいタイプのことです。特にSLA管理がチームが本当に気にする部分であればなおさらです。

価格、そして重要な関門

ここでの鋭い刃はレポートの関門です。座席あたり50ドルで、Professionalが与えてくれるのはケース管理だけで、分析やKPIレポートは一切ありません。 Microsoft Teams統合も統合ルーティングもありません。それらすべては105ドルのEnterprise座席から始まり、自分のキューを測定する能力を解放するために110%のジャンプが必要です。

さらに、Premium(195ドル)がEnterprise(105ドル)とContact Center(110ドル)を足した金額に非常に近く、20ドルの割引でバンドルされていることにも注目してください。音声は3つ目の請求書になります。注釈8には「Azure Communication Servicesの価格は別途で、含まれていません」とあり、つまり195ドルの座席が買うのはコンタクトセンターのソフトウェアであり、通話分数ではありません。

Microsoftが証明できること

ページ上のすべての証拠はMicrosoftの顧客カルーセルからのものなので、独立したものではなくベンダーが公開したものとして読んでください。最も強いのは、対応時間の20%削減を達成したLenovo、コールセンターの生産性が23%向上したLexmark、そしてサービス担当者の介入を70%削減しつつ**初回コール解決率90%**を達成したHypeです。Microsoft自身の社内導入では、プロセス時間の50%の節約を主張しています。

アナリストのポジショニングは本物です。Microsoftは、2026年3月11日に公開された2026年第1四半期のCustomer Service Solutions向けForrester Waveでリーダーであり、ServiceNowが競合する同じカテゴリーであるCRM Customer Engagement Center向けの2025年ガートナーマジック・クアドラントでもリーダーです。それでも2つのことは注目に値します。Microsoft自身によるWaveの位置づけの解説は「同等のビジョン(on-par vision)」というフレーズを使っており、これは自分自身について自発的に述べるにはめずらしく控えめな言い方です。そして推奨されているTotal Economic Impactの調査は2024年3月の日付で、それが掲載されているページより2年前のものです。

結論: サポートが顧客対応であり、ボリュームが本物で、会社がすでにDynamics上で動いている場合に正しい答えです。ライセンスと導入パートナーと販売サイクルを合わせると、問題自体よりもコストがかかる12人規模の社内ITデスクにとっては間違った答えです。その規模には、Jiraを含む、より軽量なデスクの上に構築された社内チケットシステムがより速くそこに導いてくれます。

実際にいくらかかるかを計算する

リスト価格は請求書の実際の形を隠すので、自分の数字を入力してみてください。

座席数とトグルを変更して、チームにとって4つのMicrosoftルートがどのように順位づけられるかを見てください。興味深い瞬間は、自前構築が安価な選択肢であることをやめる時点です。

10人で実行すると、自前構築ルートはDynamics Professionalの月500ドルに対して月350ドルという簡単な勝利に見えます。10人でキューにAIを乗せて実行すると、そのギャップは550ドル対700ドルに縮まりますが、それでもあなたのチームの誰かが所有しなければならないシステムのためです。その月150ドルは、あなたが見積もっていなかったパートタイムの仕事を買うことになります。

Microsoftでチケットを運用することについて人々が実際に言っていること

これについて、2020年に遡るr/sysadminとr/mspの多くのスレッドを読みました。何かを買う前に無料のチケットシステムを試す価値があるかどうかについての多くの議論も含みます。ある言い回しがほぼすべてに現れますが、それは機能比較ではありません。

「私のキャリアを通じて、『なぜダメなの?ライセンスは持っているじゃないか』というフレーズは、私が持つ最悪のプロジェクト10選のすべてのプロジェクトで、上級のビジネス職の誰か(またはプロジェクトマネージャー)によって少なくとも一度は口にされてきました。」

BrainWaveCC, Is Microsoft Dynamics 365 a viable ticketing system candidate?, Reddit

これが意思決定の推進力であり、名前をつける価値があります。「もう払っているのだから」というのは、フィット感についての議論ではなく請求書についての議論だからです。同じスレッドで、すでにコミットしていた会社の人がその結果を描写しています。

「私たちはちょうどDynamicsを既存のチケットシステムの代替として使うプロジェクトを始めました。今のところ感心していません。しかし私たちのCIOはライセンスを持っていたのでそのまま進めました。」

admlshake, Is Microsoft Dynamics 365 a viable ticketing system candidate?, Reddit

Power Appsのスレッドはより明確な線で分かれており、その分かれ目は動くかどうかではなく誰がそれを維持するかについてです。自分で構築した人たちは、それが何年も問題なく動いていると報告しています。

「Power AppsといくつかのPower Automate(以前のFlow)でチケットシステムを開発しました。私たちのデータベースはすべてSharePoint Online上にあります。2019年11月から本番稼働していて、素晴らしく動いています。」

Neiviv2828, Building a ticketing system using the MS Power Platorm?, Reddit

それを引き継いだ人たちは、まったく異なる話をしています。

「私の前任者はPower Platformを学ぶためにそれを使っていました。すばらしい……でも問題は、無料に近くて実際そんなに高くない優れたチケットシステムが世の中に何十とあるということです。だから私たちに残されたのは、見て(そして必要として)当然だと思う基本機能の90%が欠けている、バグの多いゴミでした。1週間それと格闘した後、それはゴミ箱に行きました。」

canadian_sysadmin, O365 ticketing, Reddit

どちらの話も同時に本当であり、それが両方を並べて読むことの有用な点です。自前のPower Appsキューは、たまたま事業にとって欠かせない存在になった個人プロジェクトです。 それはその作者がまだそこにいる限りだけうまく機能します。

最後のテーマは規模で、人々が挙げる数字はあなたが思うより低いです。通知やSLAのハイライトなど全部を含めてSharePointリストとPower Automateのバージョンを構築したあるシステム管理者は、その報告を明確な非推奨で終えています。

「これはお勧めしません。300人の従業員がいれば、本物のサービスデスクに投資する十分な理由になります。」

Ayy4K, O365 ticketing, Reddit

本当の選び方

ライセンスの話を取り除くと、4つの質問に帰着します。

キューは顧客対応ですか? もしそうなら、ルート1と2は飛ばして、代わりに適切なクラウドベースのチケットシステムを検討してください。5,000項目のビュー閾値と60秒のポーリング遅延は社内で許容できる問題ですが、顧客にはその許容度がありません。

それを測定する必要がありますか? 誰かが初回応答時間を尋ねるつもりなら、105ドルのEnterprise座席か、別のデスクが必要です。50ドルのプランはその質問に答えられず、Power BI上で自分でレポートを構築するには別のライセンスが追加でかかります。この同じ測定のギャップが、チケット分類がまず先に来なければならない理由です - タグ付けしたことのないカテゴリーについてレポートすることはできません。

構築を所有している人は誰かいますか? Power Appsのチケットシステムには、名前を付けたかどうかにかかわらず、メンテナーが付随してきます。答えが「私たちのITマネージャーが仕事の合間にやります」であれば、本当のコストはライセンスより高くなります。

AIが買い物の本当の理由ですか? これは最も頻繁に間違ってスコープされるものです。チームは、本当の目標が人間に届くチケットを減らすことであるときに、新しいチケットシステムを探し始めます。AIを手に入れるために再プラットフォーム化するのは、AIを購入する最も高価な方法であり、それが私のITヘルプデスクAIガイドがほとんどのケースで切り替えるより層を重ねることを主張する理由です。あなたのチームがすでにMicrosoftに深く入り込んでいるなら、最速の一手はたいてい、すでに持っているキューの上でMicrosoft Teamsサポートを自動化することです。

はっきり言っておく価値があります。これらのどれもMicrosoftを悪い選択にするものではありません。Dynamics 365は本物のアナリストの地位を持つ本気の製品であり、Power Platformは実際にパッケージ化されたヘルプデスクにはできないものを構築できます。失敗の様式はMicrosoftを選ぶことではありません。高価なほうを必要としていた問題に安価なMicrosoftルートを選び、3,000のリスト項目でそのギャップを見つけることです。どのレーンが合うかまだ決めているなら、自動化されたITチケッティングについての私のより広い考察を読んでください。

Microsoftのチケットキュー向けのeesel

デフレクションがこれを読んでいる理由で、新しいデスクではないなら、おそらく再プラットフォーム化はまったく必要ありません。

eeselは、すでに運用しているデスクとドキュメント - 社内ナレッジベースを含む - に接続するAIレイヤーです。Microsoft Teams、SharePoint、Confluence、そして既存のチケットを読み取り、チームがすでに使っているツール内で返信を作成または送信し、導入四半期ではなく数分で本番稼働します。上記のMicrosoftルートに対して特に重要な点が2つあります。クレジットではなくチケットあたりで課金されるため、財務部門に持って行く数字は予測可能な数字です。そしてすべてのロールアウトはまず過去のチケットに対してシミュレーションされるため、本番のキューに触れる前に、それが何を回答していたか、そしてどれだけうまく回答していたかを確認できます。自信があるように聞こえるボットが静かに間違った回答をするのを見てきたので、それを組み込みました。一度あれば十分です。

背後にConfluenceとSlackを持つJira Service Management上で動いているあるフィンテック企業の社内ITデスクは、eeselをそのヘルプデスクキューの一次対応として導入しました。デフレクションは55%という目標に向けて15%まで上がりました。彼らのIT責任者はこう述べています。

「私たちはJiraのヘルプデスクチケットの一次対応者としてそれを使っています。基本的にエージェントと同じように振る舞います。」

Jason Loyola, InDebtedのHead of IT

これは、Microsoftスタックに基づくITデスクが、Copilot Studioエージェントの代わりに社内ヘルプデスクにAIを導入するときに目指している同じ種類の作業ですが、クレジットの計算はありません。無料で試すことができ、セットアップにかかる時間はこの記事を読むのとおおよそ同じくらいです。

これがあなたを導く先

Microsoftチケットシステムというものは存在しません。Dynamics 365 Customer Serviceという50ドルから195ドルのCRMと、Power Platformという組み立てキットが存在します。興味深い決断は、その2つのうちどちらが実際にあなたの問題にふさわしいかです。

5つのルートは現実的で、順序があります。2人が衝突するまで共有メールボックス。3,000項目までSharePointとPower Automate。ワークフローが本当に自分のものであり、誰かがそれを所有している場合はPower Apps。目標がデフレクションであればCopilot Studio。サポートが事業そのものであればDynamics。

私がしないことは1つだけです。それは、座席を買ってAIが付属していると思い込むことです。ProfessionalとEnterpriseでは、それは含まれていません。それはMicrosoftが公開していないチケットあたりのコストを持つ単位で計測され、実際に動作する前にAzureサブスクリプションが接続されている必要があります。どのルートを取るにせよ、契約する前に、その後ではなく、そのメーターの価格を評価してください。