この記事. 説明用の想定例であり、顧客の成果ではありません。物流チームも以下の数字もすべて、説明のために置いた仮定です。設計はこうです。AIが各クレームを読み、ルールが検証し、支払いの前にすべてのクレームを人が承認します。
説明のために、従業員60人の物流会社のオペレーション責任者を想像してください。ボトルネックはクレームです。クレームはメールで届き、キューで待ち、3つのスプレッドシートにコピーされ、誰かが承認するまでに2つの手作業の確認ステップを待ちます。実在の会社ではありません。状況は仮定です。
設計は、クレームを読み、ルールに照らして確認し、承認のために担当者へ回すパイプラインです。この立場のチームなら、平均のクレーム処理時間を導入の前後で測るでしょう。この記事は、その数字がどうなるかについて何も主張しません。示すのは、オペレーションチームにとって何が変わるかです。このパターンは/ai-for/operationsの書類処理のユースケースに対応します。
オペレーションチームでは何が変わるか
仮定した状況では、3つのスプレッドシートはなくなり、2つの手作業の確認ステップもなくなります。クレームが届くと自動で読み取られて検証され、1つの承認キューに入り、レビュー担当者が承認か却下かを決めます。レビュー担当者は、以前は2ステップのうちの1つ目を担当していた同じ人です。いまは判断が必要な1ステップだけを担当します。
AIによるクレーム処理の想定例は何を示すのか
この説明用の想定例では、物流チームが3つのスプレッドシートと2つの手作業の確認ステップを、AIによる抽出、ルールベースの検証、人による承認キューに置き換えます。狙いは承認を保ったまま処理を速くすることです。すべてのクレームを引き続き人が承認します。数字は仮定であり、顧客の成果ではありません。
人間はまだ関与しているか
はい。すべてのクレームは支払い前に人間が承認します。AIは文書を読み、検証ルールを適用します。自分で何も承認しません。キューが存在するのは、確認者が生のメールと3つのタブではなく、クリーンで検証済みのクレームを見られるようにするためです。それが設計のすべてです。機械が読んで照合し、人間が判断を持ちます。
- 各クレーム文書からフィールドを抽出するAI抽出
- チームの既存ポリシーと照合するルールベースの検証
- 確認者がサインオフするまですべてのクレームを保持する人間の承認キュー
- 平均のクレーム処理時間を導入の前後で測り、その数字を追います
We are
平均のクレーム処理時間のように測れる成果を目標に設計し、すべてのクレームを人が承認します。
We aren't
支払いを自分で承認し、信頼してほしいと求める自律型のクレームボットは売っていません。
なぜ想定例と呼ぶのか
ここで公開できる顧客の成果はなく、作り上げるつもりもないからです。チームも数字も仮定なので、数字をそのまま信じるのではなく、自社のクレームの滞留に当てはめてロジックを確かめられます。名前を出せる実際の案件ができたら、根拠とともにそう明記して公開します。ほかの記事はジャーナルにあります。
オペレーションチームを率いていて、キューがボトルネックなら、上の形は再現できます。/ai-for/operationsと同じ書類処理のパターンで、AI implementationの範囲に入ります。目的は人を減らすことではありません。承認を保ったままクレームを速く処理することです。
機械が読み取りと突き合わせを行います。判断は人が持ち続けます。
改善したいキュー、滞留、処理時間があれば、何を構築しているか教えてください。始める前にスコープを書面で合意します。
