AI サポートエージェントの SLA：署名する前に解決を定義する

クローズ済みの依頼が、必ずしも完了した作業を意味するわけではありません。サービス義務ワークシートを使って、合意する前に、解決、時間の計測方法、対応責任、そして証拠を明確にしましょう。

ある顧客がアカウントレポートを必要としています。エージェントがリンクを提供し、システムはその要求を解決済みとマークします。ところが顧客がそれを再オープンします。リンクが「アクセス拒否」を返したのです。

どのイベントを完了と数えるべきでしょうか。返信か、クローズというステータスか、それとも顧客が権限のあるレポートを開けた瞬間でしょうか。

AI サポートエージェントの SLA（サービスレベル合意）は、その区別を精査可能にする必要があります。サポートチーム、調達チーム、そしてサプライヤーは、その作業とその証拠について共通の理解を持つ必要があります。

まず1件の要求から始め、そのイベントを追いましょう。以下のワークシートは、成功ラベルがサービス上の約束になる前に、何が未決定のまま残っているかを特定するのに役立ちます。

概要

• 対象となる顧客の作業と、その成果を受理可能にする証拠を定義しましょう。請求の適格性は別にマッピングします。
• 各サービス時間の計測を開始・停止・一時停止させるイベントを合意しましょう。同じ要求が再オープンされたり引き継ぎされたりした場合に何が起こるかも含めます。
• 証拠、コミュニケーション、そして争いのある成果について、それぞれの担当者を定めましょう。ステータスラベルがそれらを決着させると仮定するのではなく、実際の条項と結果をレビューしましょう。

どのサービス上の約束を計測しているのか

AI サポートエージェントの SLA は、いくつかの異なる約束を対象にし得ます。可用性、適格な応答、そして使用可能な完了作業は、必ずしも1つの指標や停止イベントを共有するわけではありません。

あるサービスレベル指標、すなわち SLI は、サービスのある側面を計測します。あるサービスレベル目標、すなわち SLO は、その計測に対する目標を設定します。

Google の SRE ブックでは、SLA を「そこに含まれる SLO を満たす（または満たさない）ことの結果を含む」合意だと説明しています。したがって SLO は本質的に内部向けというわけではなく、SLA の一部を構成し得ます。

これらの区別を、あなたが購入しようとしている作業に当てはめましょう。利用可能なサービスであっても、使用不能なレポートリンクを提供してしまうことがあります。適格な回答の前に、迅速な受領確認が存在することもあります。

請求はまた別の問いを投げかけます。たとえば Zendesk は、請求に関する自動解決を、人へのエスカレーションなしに AI エージェントが正常に解決した要求と説明しています。その定義は、あなたが選ぶサービス受理ルールを成立させるものではなく、あらゆる再オープンのシナリオを説明するものでもありません。

語彙だけでなく、ポリシーの適用範囲も確認しましょう。従来のチケット指標は、AI エージェントとのやり取り、あらゆるチャネル、あるいはあらゆる応答タイプを自動的に対象とするわけではありません。

計測と構成のコンテキストについては、サービスレベルの時間の計測と目標に関する DevRev のリファレンスを参照してください。それは、どの作業・証拠・結果が適用されるかについての当事者間の合意に取って代わるものではありません。

まだ解決されていなかったクローズ済みの要求

同じ要求が、もっともらしい完了タイムスタンプを複数生み出すことがあります。あるタイムスタンプを約束の評価に使う前に、それぞれが何を成立させるのかを判断する必要があります。

例示的ケース：以下のイベントはすべて架空のものです。これは実行された製品テストでも、顧客の実際の結果でも、ベンダーの請求書でもありません。

ケース A は、顧客が受け取る権限を持つアカウントレポートに関するものです。すべてのイベントは同じ日に、1つのタイムゾーンで、この例の対応時間枠の中で発生します。有効な一時停止イベントは無いものとします。

受領確認には2分、実質的な返信には6分、ステータスのクローズには8分かかりました。検証済みの結果は70分後に到着しました。対応責任の受理はその間に発生しましたが、それによって要求が完了したわけではありません。

これらは受領からの経過時間であって、SLA が満たされた・満たされなかったという判定ではありません。期限や契約上の停止ルールは一切提供されていません。

再オープンは、以前の試行を隠す新しい要求を作り出すのではなく、ケース A に紐づけたままにしましょう。計測が継続するか、再開するか、変化するかは、適用される合意済みのルールに従わなければなりません。

請求候補フラグも未解決のままです。調達は、請求書についての結論を導く前に、再オープンや人の関与の取り扱いを含め、実際の商取引上の定義を確認しなければなりません。この例の中には、顧客に請求が行われたことを成立させるものは何もありません。

AI サポートエージェント SLA ワークシート

サービス上の問い、必要な証拠、そして未解決の判断をひとまとめにしましょう。そうすることで、このワークシートは、合意を交渉する人にとっても、それを運用することを期待されるチームにとっても有用になります。

これは教育目的のワークシートであって、そのままコピーして署名する契約文言ではありません。目標値や救済措置は、責任ある当事者が決着させるまで未決のままにしておきましょう。提案された契約文言や解釈は、法務がレビューすべきです。

請求の行は、どのサービスが提供されたかを成立させる行とは分けておきましょう。この2つの判断は、異なる証拠を必要とする場合があります。

エージェントが作業の一部を実行する場合は、証拠レビューのための実行記録を使いましょう。記録されたツール呼び出しは試行の説明には役立ちますが、それ自体では、顧客が使用可能な結果を受け取ったことを成立させません。

ケース A については、失敗したリンクと、最終的なアクセス検証の両方を保全しましょう。失敗した試行を取り除くと、最終結果が、実際のシーケンスが許す以上に解釈しやすく見えてしまいます。

署名前に検証すべきものは何か

未解決のワークシートの問いを、それぞれに答えられる役割に割り当てましょう。有用なレビューは、未確認の保証の寄せ集めではなく、証拠と合意された解釈で終わります。

サポートオペレーションは、対象となる要求と、それを完了にする成果を定義すべきです。提案された時間計測のルールを使って、再オープンと引き継ぎのイベントを一通り確認しましょう。顧客が後から返信した場合や、作業が対応境界をまたぐ場合でも、同じルールが依然として妥当かを問いましょう。

技術担当者は、選定したワークフローを実演し、それがどの記録を生成するかを示すべきです。成功した試行だけでなく失敗した試行も精査し、返されたリンク、受理した人の担当者、そして使用可能な結果を証拠が区別しているかを確認しましょう。あらゆるプラットフォームが同じフィールドを公開していると仮定してはいけません。

調達は、サービスワークシートを、適用される商取引上の定義と突き合わせるべきです。どの条項が争いのある候補イベントを規定するか、そしてその突き合わせを説明できるのは誰かを特定しましょう。ダッシュボード上の請求ラベルは、そのレビューの代わりにはなりません。

セキュリティは、適切な証拠へのアクセスと取り扱いを決定すべきです。買い手は、合意された成果を精査するのに十分な情報を必要とするのであって、すべての顧客記録や非公開のトレースへの無制限なアクセスを必要とするわけではありません。必要な証拠が、意図された権限のもとで指定のレビュー担当者と共有できるかを確認しましょう。

法務は、提案された条項、除外事項、結果、責任、そして争いのあるイベントの解釈をレビューすべきです。ワークシートはそのレビューのための問いを特定しますが、承認済みの条項を提供したり、強制力を成立させたりはしません。依存関係の失敗にも、除外ラベルだけでなく、合意された調査とコミュニケーションの担当者が必要です。

より広範な調達プロセスについては、署名前の評価証拠を活用してください。

Computer, by DevRev を評価する際は、選定したワークフローとワークシートを使いましょう。どの操作と関連する証拠が実演可能で、どれが構成やさらなる検証に依存するのかを問いましょう。実演は議論の材料になりますが、合意されたサービス条項を生み出すものではありません。

1つのサポートワークフローを、曖昧なイベントを見える状態のまま次の議論に持ち込みましょう。どのイベントが使用可能な結果を成立させるのか、どの記録がそれを裏付けるのか、そして残るタイミングや商取引上の問いを解決しなければならないのは誰かを問いましょう。

ワークシートを使って、実演が示すものと、当事者が実際に合意したものとを切り分けましょう。その区別は、最も安心できる成功ラベルを選ぶことよりも重要です。

デモをリクエストすることで、あなたのワークフローについて何が実演可能かを掘り下げましょう。