クロード共通ユースケースガイド：作業指示の割り当て

このガイドでは、クロードの高度な自然言語理解機能を活用して、顧客の意図、緊急度、優先度、顧客プロファイルなどの要因に基づいて、カスタマーサポートの作業指示を大規模に分類する方法について説明します。

作業指示の割り当てにクロードを使用するかどうかの定義

ここでは、分類タスクに従来の機械学習手法ではなく、ClaudeのようなLLM（大規模言語モデル）を使用すべきことを示す主な指標をいくつか紹介する：

利用可能なアノテーション・トレーニング・データが限られている

従来の機械学習プロセスでは、大規模な注釈付きデータセットが必要でした。クロードの事前学習済みモデルは、わずか数十の注釈付き例を使用して作業指示を効率的に分類することで、データ準備の時間とコストを大幅に削減できます。

お客様の分類カテゴリーは、時間の経過とともに変更または進化する可能性があります。

従来の機械学習手法が確立された後、それを修正するのは時間がかかり、データ集約的なプロセスになりかねません。一方、製品や顧客のニーズが変化すると、クロードはトレーニングデータの大規模な再ラベリングなしに、カテゴリー定義の変更や新しいカテゴリーに簡単に適応することができます。

構造化されていない複雑なテキスト入力を処理する必要がある

従来の機械学習モデルは、非構造化データに苦戦することが多く、大規模な特徴エンジニアリングを必要とします。クロードの高度な言語理解は、厳密なオントロジー構造に依存することなく、コンテンツとコンテキストに基づく正確な分類を可能にします。

分類ルールは意味理解に基づく

伝統的な機械学習手法は、しばしば単語袋モデルや単純なパターンマッチングに依存している。カテゴリーが例ではなく条件によって定義されている場合、クロードはこれらの基本的なルールを理解し適用することに優れている。

カテゴリー別の決定には解釈可能な推論が必要

従来の機械学習モデルの多くは、意思決定プロセスについての洞察をほとんど提供しない。claudeは、分類決定について人間が読める説明を提供できるため、自動化されたシステムに対する信頼が高まり、必要に応じて容易に適応することができる。

エッジケースや曖昧な作業指示をより効果的に処理したい。

従来の機械学習システムは、通常、異常やあいまいな入力を処理するときにパフォーマンスが悪く、しばしば誤分類したり、「キャッチオール」カテゴリーに割り当てたりします。クロードの自然言語処理機能は、サポート作業指示の文脈やニュアンスをよりよく解釈することを可能にし、人間の介入を必要とする誤分類や未分類の作業指示の数を減らす可能性があります。手作業による介入を必要とする誤分類や未分類の作業指示の数が減る可能性がある。

複数のモデルを維持することなく、多言語サポートを提供する必要があります。

従来の機械学習アプローチでは、サポートする言語ごとに個別のモデルを維持したり、大規模な翻訳プロセスを実行したりする必要がありました。Claudeの多言語機能は、個別のモデルや大規模な翻訳プロセスを必要とせずに、さまざまな言語で作業指示を分類することを可能にし、グローバルな顧客サポートを簡素化します。

ワークフローをサポートするビッグ言語モデルの構築と展開

現在のサポート方法を知る

自動化に取り組む前に、まず既存の作業指示システムを理解することが重要です。まず、サポートチームが現在どのように作業指示ルーティングを処理しているかを調査することから始めましょう。

以下のような質問が考えられる：

• 適用されるSLA/サービスプランは、どのような基準で決定されましたか？
• ワークオーダールーティングは、どのサポートレベルまたは製品スペシャリストにワークオーダーを送るべきかを決定するために使用されていますか？
• 自動化されたルールやワークフローはすでに導入されているか？どのような状況で失敗しますか？
• エッジケースやファジーな作業指示はどのように処理されるのか？
• チームはどのように作業指示に優先順位をつけるのか？

人間が特定の状況にどのように対処するかを知れば知るほど、より良いコミュニケーションをとることができる。 クロード タスクの共同作業。

ユーザーの意図カテゴリーを定義する

Claude.Claudeがシステム内で効果的に作業指示をルーティングする能力は、システム内のカテゴリ定義の明確さに直接関係しています。

以下は、ユーザーインテントのカテゴリとサブカテゴリの例です。

技術的な問題

• ハードウェアの問題
• ソフトウェアの脆弱性
• 相性問題
• パフォーマンスの問題

アカウント管理

• パスワードのリセット
• アカウントアクセスの問題
• 請求照会
• サブスクリプションの変更

製品情報

• 機能に関するお問い合わせ
• 製品互換性の問題
• 価格情報
• 空席照会

ユーザーガイド

• 操作ガイド
• 機能ヘルプ
• ベストプラクティスの推奨
• トラブルシューティングガイド

情報を送り返す

• 脆弱性報告
• 機能リクエスト
• 一般的なご意見
• と文句を言う。

オーダー関連

• ご注文状況のお問い合わせ
• 物流情報
• 商品を返品する
• 注文の変更

サービスリクエスト

• 設置支援
• エスカレーションリクエスト
• メンテナンスプログラム
• サービスキャンセル

セキュリティ問題

• 個人情報に関するお問い合わせ
• 疑わしい活動報告
• 安全機能

コンプライアンスと法務

• 規制遵守の問題
• 利用規約に関するお問い合わせ
• 法的文書の請求

緊急サポート

• 重要システムの故障
• 緊急時のセキュリティ問題
• 時間に敏感な問題

トレーニングと教育

• 製品トレーニングのリクエスト
• ドキュメント検索
• ウェビナー・ワークショップ情報

統合とAPI

• 統合支援
• API利用の問題
• サードパーティとの互換性チェック

ワークオーダーのルーティングと優先順位付けは、ユーザーの意図に加え、緊急度、顧客のタイプ、SLA、言語などの他の要因にも影響されます。自動ルーティングシステムを構築する際には、その他のルーティング基準も考慮するようにしてください。

成功基準の確立

サポートチームと協力して、測定可能なベンチマーク、しきい値、目標を使用する。明確な成功基準を定める.

以下は、作業指示の割り当てにラージ・ランゲージ・モデル（LLM）を使用する場合の一般的な基準とベンチマークである：

分類の一貫性

この指標は、クロードが類似の作業オーダーを長期にわたって分類する際の一貫性を評価するものである。これは配賦の信頼性を維持するために非常に重要である。標準化された一連の入力テストモデルを定期的に使用することで、95%以上の一貫性を目標としています。

適応速度

この指標は、クロードが新しいカテゴリーや変化する業務オーダーのパターンにいかに早く適応するかを測定する。これは、新しい作業オーダーのタイプを導入し、これらの新しいカテゴリーにおいてモデルが満足のいく精度（例えば、>90%）を達成するのにかかる時間を測定することによって行われる。目標は、50～100 サンプル作業オーダー内で適応を達成することである。

多言語処理

この評価指標は、クロードが多言語での作業指示を正確に割り当てる能力を評価する。異なる言語での割り当て精度を測定し、非ドミナント言語では5-10%以上精度を落とさないことを目標とする。

エッジケース処理

この指標は、一般的でない、または複雑な作業指示を処理する際のクロードのパフォーマンスを評価する。これらの複雑な入力に対して、少なくとも801 TP3Tの割り当て精度を達成することを目標に、エッジケースのテストセットが作成される。

バイアスが減少する

この指標は、異なる顧客グループ間でのクロードの配分の公平性を測定します。割り当ての決定は、すべての顧客グループにわたって一貫した割り当て精度（2～3%以内）を目標に、潜在的な偏りがないか定期的に見直されます。

キューの効率

この基準は、トークンの数を減らす必要がある最小限のコンテキスト条件下でのクロードのパフォーマンスを評価する。異なる量のコンテキストが提供された場合の割り当て精度を測定し、作業指示のタイトルと短い説明のみが提供された場合に 90% 以上の精度を達成することを目標とする。

解釈可能性スコア

この指標は、クロードの配分決定に関する説明の質と妥当性を評価するものである。人間の評価者は、平均評価4以上を目標に、説明を採点（例えば1～5）することができます。

ここでは、大規模な言語モデルを使用するか否かにかかわらず共通する成功基準をいくつか紹介する：

流通精度

割り当て精度は、作業オーダーが最初に正しいチームまたは個人に正しく割り当てられたかどうかを測定します。通常、正しく割り当てられた作業指示の割合として測定される。業界のベンチマークでは、通常90～95%の精度を目標としていますが、これはサポート構造の複雑さによって異なります。

スロット

この指標は、作業指示書が提出された後、どれだけ早く割り当てられるかを追跡します。通常、割り当て時間が早ければ、解決も早くなり、顧客満足度も高くなる。最適なシステムの平均割り当て時間は通常5分未満であり、多くのシステムはほぼ瞬時の割り当て（LLMを使用すると可能）を目指している。

再分配率

再割当率は、最初の割当の後、どれくらいの頻度で作業指示を再割当する必要があるかを示す。再配分率が低いほど、初期配分がより正確であることを示す。目標は、再配分率を101 TP3T以下に抑えることであり、最もパフォーマンスの高いシステムは51 TP3T以下を達成している。

初回接触解決率

この指標は、最初の顧客との対話で解決された作業指示の割合を測定します。初回解決率が高いほど、効率的な割り当てと準備の整ったサポートチームであることを示します。業界のベンチマークは通常70～75%で、トップクラスのチームは80%以上の初回解決率を達成しています。

平均処理時間

平均処理時間は、作業指示を最初から最後まで解決するのにかかる時間を測定する。効果的な割り当てにより、この時間を大幅に短縮することができる。ベンチマークは業種や複雑さによって異なりますが、多くの組織は緊急性のない問題の平均処理時間を24時間未満に抑えることを目指しています。

顧客満足度

通常、対話後のアンケート調査によって測定されるこれらの評価は、サポートプロセスに対する顧客の全体的な満足度を反映している。効果的なディストリビューションは満足度に貢献する。目標は、顧客満足度（CSAT）90%以上を達成することであり、最も成績の良いチームは95%以上の満足度を達成しています。

昇格率

この指標は、ワークオーダーをより高いレベルのサポートにエスカレーションする必要がある頻度を測定する。エスカレーション率が低いほど、通常、初期割り当てがより正確であることを示す。目標は、エスカレーション率を 201 TP3T 以下に抑えることであり、最適なシステムは 101 TP3T 以下のエスカレーション率を達成する。

従業員の生産性

この指標は、ディストリビューション・ソリューションの導入後、サポートスタッフが効率的に処理できるワークオーダーの数を測定する。ディストリビューションの改善は、生産性の向上につながるはずである。1日または1時間あたり、従業員1人あたりが解決した作業オーダーの数を追跡することによって測定され、目標は、新しいディストリビューション・システムを導入した後、生産性を10-20%向上させることである。

セルフサービスのトリアージ率

この指標は、潜在的な作業指示のうち、流通システムに入る前にセルフサービス・オプションを通じて解決されたものの割合を測定する。トリアージ率が高いほど、割り当て前のトリアージが効果的であることを示す。目標は、20～301 TP3Tのトリアージ率を達成することであり、最も成績の良いチームは401 TP3T以上を達成する。

作業指示1件あたりのコスト

この指標は、各サポート・ワークオーダーを解決するための平均コストを計算する。効率的なディストリビューションは、長期的なコスト削減に役立つはずである。ベンチマークは大きく異なるが、多くの組織は、改善されたディストリビューション・システムを導入した後、ワークオーダーあたりのコストを10～151 TP3T削減することを目標としている。

適切なクロード・モデルの選択

モデルの選択は、コスト、精度、応答時間のトレードオフに依存する。

多くの顧客が claude-3-haiku-20240307 Claude 3 ファミリーの中で最も高速で費用対効果の高いモデルでありながら、優れた結果を提供するため、作業指示ルーティングの処理に最適です。分類の問題に深い専門知識が必要な場合、または多くの複雑な意図的カテゴリー推論が必要な場合は、次のモデルを選択できます。 大きなソネット・モデル.

強力なチップを作る

Claude はサポート作業オーダーの内容を分析し、問題の種類、緊急度、必要な専門知識、その他の関連要因に基づいて、事前に定義されたカテゴリーに分類します。

作業指示の分類のためのプロンプトを書いてみよう。最初のプロンプトはユーザーリクエストの内容を含み、推論プロセスと意図を返す。

を試すことができる。 アンソロピック・コンソール アップ チップジェネレーター クロードにプロンプトの最初のバージョンを書いてもらおう。

以下は、作業指示のルーティング分類プロンプトの例です：

def classify_support_request(ticket_contents):
    # 为分类任务定义提示
    classification_prompt = f"""你将作为客户支持工单分类系统。你的任务是分析客户支持请求，并输出每个请求的适当分类意图，同时给出你的推理过程。

        这是你需要分类的客户支持请求：

        <request>{ticket_contents}</request>

        请仔细分析上述请求，以确定客户的核心意图和需求。考虑客户询问的内容和关注点。

        首先，在 <reasoning> 标签内写出你对如何分类该请求的推理和分析。

        然后，在 <intent> 标签内输出该请求的适当分类标签。有效的意图包括：
        <intents>
        <intent>支持、反馈、投诉</intent>
        <intent>订单追踪</intent>
        <intent>退款/换货</intent>
        </intents>

        一个请求只能有一个适用的意图。只包括最适合该请求的意图。

        例如，考虑以下请求：
        <request>您好！我在周六安装了高速光纤网络，安装人员 Kevin 的服务非常棒！我在哪里可以提交我的正面评价？谢谢您的帮助！</request>

        这是你的输出应该如何格式化的示例（针对上述请求）：
        <reasoning>用户希望留下正面反馈。</reasoning>
        <intent>支持、反馈、投诉</intent>

        这里有几个更多的示例：
        <examples>
        <example 2>
        示例 2 输入：
        <request>我想写信感谢你们在上周末我父亲的葬礼上对我家人的关怀。你们的员工非常体贴和乐于助人，这让我们肩上的负担减轻了不少。悼念手册非常漂亮。我们永远不会忘记你们对我们的关爱，我们非常感激整个过程的顺利进行。再次感谢你们，Amarantha Hill 代表 Hill 家庭。</request>

        示例 2 输出：
        <reasoning>用户留下了他们对体验的正面评价。</reasoning>
        <intent>支持、反馈、投诉</intent>
        </example 2>
        <example 3>

        ...

        </example 8>
        <example 9>
        示例 9 输入：
        <request>你们的网站一直弹出广告窗口，挡住了整个屏幕。我花了二十分钟才找到电话投诉的号码。我怎么可能在这些弹出窗口的干扰下访问我的账户信息？你能帮我访问我的账户吗，因为你们的网站有问题？我需要知道在档的地址。</request>

        示例 9 输出：
        <reasoning>用户请求帮助以访问其网络账户信息。</reasoning>
        <intent>支持、反馈、投诉</intent>
        </example 9>

        请记住，始终在实际意图输出之前包括分类推理。推理应包含在 <reasoning> 标签内，意图应包含在 <intent> 标签内。仅返回推理和意图。
        """

そのヒントの重要な部分を分解してみよう：

• Pythonのf-stringを使用して、ヒントのテンプレートを作成する。 ticket_contents に挿入する。 <request> タグ別アーカイブ
• 私たちは、作業指示の内容を注意深く分析し、顧客の核心的な意図とニーズを見極める分類システムとして、クロードの役割を明確に定義した。
• でクロードに正しい出力形式を指示した。 <reasoning> 推論と分析はタグの中で行われ、その後 <intent> タグの中に適切なカテゴリータグを出力する。
• 当社は、「サポート、フィードバック、苦情」、「注文追跡」、「払い戻し/交換」という有効な意図カテゴリを指定しています。
• いくつかの例（すなわち、数発のヒント）は、正確さと一貫性を向上させるのに役立つ、出力がどのようにフォーマットされるべきかを説明するために提供されています。

私たちは、正規表現を使用して理由と意図を別々に抽出できるように、Claude に応答を個別の XML タグセクションに分割させたいと考えています。これにより、例えば、作業オーダーのルーティングワークフローにおいて、誰に作業オーダーをルーティングするかを決定するためにインテントのみを使用するなど、的を絞った後続ステップを作成することができます。

キュー・ワードの配置

テスト本番環境にデプロイされていない場合、および 運用評価しかし、自分のキュー・ワードがどれだけ効果的なのかはわからない。

デプロイメント構造を構築しよう。Claudeへの呼び出しをラップするメソッド・シグネチャを定義することから始めよう。すでに書き始めたメソッドを使う。 ticket_contents を入力として返す。 reasoning 歌で応える intent タプルを出力する。すでに伝統的な機械学習を使った自動化手法を持っている場合は、その手法のシグネチャーに従うことが推奨される。

import anthropic
import re

# 创建一个 Anthropic API 客户端实例
client = anthropic.Anthropic()

# 设置默认模型
DEFAULT_MODEL="claude-3-haiku-20240307"

def classify_support_request(ticket_contents):
    # 为分类任务定义提示词
    classification_prompt = f"""你将作为客户支持工单的分类系统。
        ...
        ... 推理结果应包含在 <reasoning> 标签中，意图应包含在 <intent> 标签中。仅返回推理和意图。
        """
    # 将提示词发送到 API 以对支持请求进行分类
    message = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=500,
        temperature=0,
        messages=[{"role": "user", "content": classification_prompt}],
        stream=False,
    )
    reasoning_and_intent = message.content[0].text

    # 使用 Python 的正则表达式库提取 `reasoning`
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # 同样提取 `intent`
    intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
    intent = intent_match.group(1).strip() if intent_match else ""

    return reasoning, intent

このコード

• Anthropicライブラリをインポートし、APIキーを使用してクライアントインスタンスを作成します。
• を定義する。 classify_support_request 関数は ticket_contents ストリング。
• 利用する classification_prompt そうしれいかん ticket_contents クロードに送って選別してもらう。
• のレスポンスから抽出したモデルを返します。 reasoning 歌で応える intent.

構文解析の前に、完全な推論とインテント・テキストの生成を待つ必要があるので、次のようにする。 stream=False デフォルト値に設定。

ヒントを評価する

キュー・ワードの使用は、通常、プロダクション・レディのステータスに到達するためのテストと最適化を必要とする。ソリューションが準備できているかどうかを判断するには、事前に設定した成功基準としきい値に基づいてパフォーマンスを評価します。

評価を実行するには、評価を実行するためのテストケースが必要です。この記事ではテストケースの開発.

評価関数の構築

本ガイドに掲載されている評価のサンプルは、3つの主要な指標によってクロードのパフォーマンスを測定しています：

• 精度
• 分類ごとのコスト

あなたにとって何が重要かによって、クロードを他の次元で評価する必要があるかもしれない。

評価を実行するためには、まず、予測された意図と実際の意図を比較し、予測の正しさの割合を計算する関数を追加することによって、前のスクリプトを修正する必要があります。また、原価計算機能と時間計測機能も追加する必要がある。

import anthropic
import re

# 创建 Anthropic API 客户端的实例
client = anthropic.Anthropic()

# 设置默认模型
DEFAULT_MODEL="claude-3-haiku-20240307"

def classify_support_request(request, actual_intent):
    # 定义分类任务的提示
    classification_prompt = f"""You will be acting as a customer support ticket classification system. 
        ...
        ...The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the intent.
        """

    message = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=500,
        temperature=0,
        messages=[{"role": "user", "content": classification_prompt}],
    )
    usage = message.usage  # 获取 API 调用的使用统计信息，包括输入和输出 Token 数量。
    reasoning_and_intent = message.content[0].text

    # 使用 Python 的正则表达式库提取 `reasoning`。
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # 同样，提取 `intent`。
    intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
    intent = intent_match.group(1).strip() if intent_match else ""

    # 检查模型的预测是否正确。
    correct = actual_intent.strip() == intent.strip()

    # 返回推理结果、意图、正确性和使用情况。
    return reasoning, intent, correct, usage

コードに加えた変更は以下の通り：

• 私たちは actual_intent テストケースから classify_support_request そして、クロードの意図分類が我々の黄金意図分類と一致しているかどうかを評価するために、比較メカニズムが設定された。
• 入出力トークンの使用量に基づいてコストを計算するために、API 呼び出しの使用量統計を抽出した。

アセスメントの実施

よく練られた評価には、何が良い結果を構成するかを決定するための明確な閾値とベンチマークが必要です。上記のスクリプトは、精度、応答時間、分類あたりのコストに関する実行時の値を提供してくれますが、それでもやはり、明確に設定されたしきい値が必要です。例

• 正確さ： 95%（100テスト）
• 分類ごとのコスト： 現行のルーティング方法と比較して、平均50%の削減（100テスト

これらのしきい値を設定することで、どのアプローチが最適かを迅速かつ容易に規模に応じて判断することができ、偏りのない経験的データにより、要件をよりよく満たすためにどのような改善が必要かを明確にすることができる。

パフォーマンスを向上させる

複雑なシナリオの場合は、標準的なものを超えるものを検討する。 迅速なエンジニアリング技術 歌で応える ガードレール導入戦略 の追加戦略が役に立つかもしれない。よくあるシナリオをいくつか挙げてみよう：

20以上のインテント・カテゴリーがある場合は、分類階層を使用します。

カテゴリの数が増えると、必要な例の数も増え、プロンプトが扱いにくくなります。代替案として、ハイブリッド分類器を使った階層的な分類システムの実装を検討してもよいでしょう。

1. 意図を分類ツリー構造に整理する。
2. ツリーの各レベルで一連の分類器を作成し、カスケード・ルーティング法を有効にする。

たとえば、作業オーダーを「技術的な問題」、「請求に関する問題」、「一般的な問い合わせ」に大別するトップレベルの分類器があるとします。これらの各カテゴリは、さらに分類を絞り込むための独自のサブ分類器を持つことができます。

• メリット - ニュアンスと正確性が増す： 親パスごとに異なるプロンプトを作成できるため、より的を絞った状況に応じた分類が可能になります。これにより、精度が向上し、顧客のリクエストをよりきめ細かく処理できるようになります。
• デメリット - 待ち時間が増える： 複数の分類器を使用すると、待ち時間が長くなる可能性があるので、最速モデルのHaikuを使用する場合は、この方法を実行することをお勧めします。

ベクトル・データベースと類似検索を使用して、変化の激しい作業指示を処理する。

例を提示することはパフォーマンスを向上させる最も効果的な方法ですが、サポートリクエストのばらつきが大きい場合、1回のプロンプトに十分な例を含めることは難しいかもしれません。

この場合、ベクトルデータベースを使用して、例データセットから類似性検索を実行し、与えられたクエリに最も関連する例を取得することができます。

この方法論は、我々の 分類方法 詳しくは、71%の精度を93%の精度に改善することが示されている。

想定されるエッジケースを特別に考慮

以下は、クロードが作業指示を誤って分類する可能性のあるいくつかのシナリオです (あなたの状況に特有な状況が他にもあるかもしれません)。これらのシナリオでは、クロードがエッジケースをどのように扱うべきか、プロンプトに明確な指示や例を示すことを検討してください：

クライアントは暗黙の要求をする

顧客はしばしば間接的にニーズを表現する。例えば、「小包を2週間以上待っている」というのは、注文状況に対する間接的な要求かもしれない。

• 解決策 クロードに、このタイプの要求とその根底にある意図について、実際の顧客の例をいくつか提示してください。作業指示の意図について特に微妙な分類の根拠を含めれば、クロードが他の作業指示にロジックを一般化できるように、より良い結果を得ることができます。

クロードは意図よりも感情を優先する

クライアントが不満を表明すると、クロードは根本的な問題を解決するよりも、感情に対処することを優先するかもしれない。

• 解決策 クロードに、顧客感情を優先するタイミングを示す。これは、「顧客感情をすべて無視する。顧客からのリクエストの意図と、顧客が求めている情報の分析だけに集中する。"

複数の課題があるため、課題の優先順位付けに混乱が生じる

クロードは、顧客が1回の対話で複数の質問をした場合、主な懸念を特定するのが難しいかもしれない。

• 解決策 意図の優先順位を明確にすることで、クロードが抽出された意図の優先順位をより明確にし、主要な懸念を特定できるようにする。

クロードをより大きなサポートワークフローに統合する

適切な統合を行うには、クロード ベースの業務オーダ ルーティング スクリプトを大規模な業務オーダ ルーティング システム アーキテクチャにどのように適合させるかを決定する必要がありま す。これには、次の 2 つの方法があります：

• プッシュ型： あなたが使用しているサポートワークオーダーシステム（例：Zendesk）は、ルーティングサービスにウェブフックイベントを送信することで、あなたのコードをトリガーします。
  • このアプローチはよりネットワーク・スケーラブルだが、エンドポイントを公開する必要がある。
• プルベース： あなたのコードは、指定されたスケジュールに基づいて最新の作業オーダーをプルし、プルされると同時にそれをルーティングする。
  • この方法は実装が簡単だが、あまり頻繁に実行すると、サポートする作業指示システムに不必要な呼び出しが発生する可能性がある。

どちらの方法でも、スクリプトをサービスでラップする必要があります。どちらの方法を選択するかは、サポート・ワークオーダー・システムがどのようなAPIを提供するかによって決まります。