Customer Operations

CS 回答 / 返金判断 を viyv で動かす。

チケット、契約情報、FAQ、自社 admin を見ながら回答を作っている。AI で一次回答を速くしたいが、顧客情報の露出、誤送信、返金判断の責任境界が曖昧。

CS Ops、サポート、業務企画viyv Agent Foundry / viyv Browser / viyv DB
Customer support agent workflow

Problem

この業務で、何が詰まっているか。

チケット、契約情報、FAQ、自社 admin を見ながら回答を作っている。AI で一次回答を速くしたいが、顧客情報の露出、誤送信、返金判断の責任境界が曖昧。

始めるきっかけ

問い合わせ一次回答、返金可否確認、契約変更依頼、障害影響調査。

最初の 30 日

よくある問い合わせカテゴリを 1 つ選び、回答下書きと送信前承認を検証します。返金や契約変更は実行せず、承認 UI と audit をレビュー対象にします。

Day In The Life

現場の 1 件が、判断材料までどう流れるか。

業務詳細では、担当者が何を持ち込み、AI がどこまで進め、人間がどこで止め、 最後に何を証拠として残すかを時系列で確認します。

Start

担当者が 1 件を選ぶ

問い合わせ一次回答、返金可否確認、契約変更依頼、障害影響調査。 から 1 件を選び、対象画面、社内 tool、AI に渡せる情報、人間に戻す判断を固定します。

Assist

AI が下調べと下書きを行う

Agent Foundry で CS 調査 agent を定義する。Browser がログイン済み admin とチケット画面を read-only で参照する。AI が回答文、社内メモ、返金可否の根拠を下書きする

Gate

責任が残る操作を止める

メール / チケット送信 / 返金実行 / 契約変更 / 登録情報変更 は approval、差戻し、保留、または人間確認に戻します。

Review

判断材料に使う証拠を残す

一次回答時間 / 送信前 approval / 拒否理由 / 問い合わせ履歴の再利用 を検証の evidence として並べ、次の展開可否を決めます。

業務ごとの AI 実行、承認ゲート、監査証跡、レビュー材料を示す抽象ダッシュボード

Operational Evidence Board

CS 回答 / 返金判断 の現場実行を、レビュー用の証拠にする。

担当者が見たもの、AI が出した下書き、人間が止めた判断、レビュー会議に出す証拠を 1 つの board にします。これにより「便利そう」ではなく、運用に入れてよいかを判断できます。

Ticket

問い合わせを回答下書きに変える

担当者が見るもの

CS 担当がチケット ID、顧客要望、参照してよい FAQ / 契約情報を指定する。

AI の出力

AI は契約状況、過去対応、FAQ を読み、回答文、社内メモ、返金可否の根拠を下書きする。

人間が止める判断

メール送信、返金、契約変更、顧客情報更新は approval 待ちにする。

レビューに出す証拠

一次回答時間、下書き修正率、送信前 approval、返金拒否理由を比較する。

Escalation

返金条件が曖昧なら送信しない

担当者が見るもの

担当者が AI の根拠を読み、返金条件に不足があれば承認者に escalate する。

AI の出力

AI は返金可、返金不可、追加確認の理由を分け、再下書き候補を出す。

人間が止める判断

承認者が拒否した場合、拒否理由を AI に返し、送信ではなく再下書きに戻す。

レビューに出す証拠

拒否理由、再下書き品質、SLA 影響、返金実行が止まった audit を残す。

Rollout

カテゴリ別に CS agent を育てる

担当者が見るもの

CS Ops が対象カテゴリを 1 つ選び、採用された回答と修正理由を agent definition に反映する。

AI の出力

Agent Foundry が version、tool call、run history、waiting_input を保持する。

人間が止める判断

未承認 draft の deploy と highly restricted data を扱う agent を止める。

レビューに出す証拠

採用率、修正理由、agent version、送信 / 返金 approval を部門展開の判断に使う。

Before / After / Recovery

利用前後と、失敗時の戻し方を同じ画面で見る。

利用前の不安は、効果よりも「失敗した時に止められるか」で出ます。利用前、運用後、 失敗時、レビュー会議で見る材料を並べます。

利用前

チケット、契約情報、FAQ、自社 admin を見ながら回答を作っている。AI で一次回答を速くしたいが、顧客情報の露出、誤送信、返金判断の責任境界が曖昧。

運用後

Agent Foundry で CS 調査 agent を定義する。Browser がログイン済み admin とチケット画面を read-only で参照する。AI が回答文、社内メモ、返金可否の根拠を下書きする。送信、返金、登録、契約変更は承認待ちにして担当者へ戻す。

失敗時

回答根拠が不足している場合は送信せず調査メモに戻す / 返金条件が曖昧な場合は承認者に escalate する / 顧客情報が mask されない場合は AI 呼び出しを拒否する

レビュー会議

現場指標: 一次回答時間、下書き修正率、SLA 影響 / 統制指標: 送信 / 返金 approval、顧客情報 mask、拒否理由 / 導入判断: CS 品質を落とさず、責任境界を人間へ戻せるか

Scenario Walkthrough

現場の 1 件を、運用後の流れまで具体化する。

利用検討で必要なのは、抽象的な自動化ではなく「この 1 件がどう変わるか」です。現在の作業、viyv 後の処理、解決する問題、レビュー会議で見る判断材料を分けます。

Customer support agent workflow

Case

返金相談チケットで、契約状況と過去対応を見て回答下書きを作る

CS 担当者はチケット、契約情報、FAQ、admin、過去対応を見て回答を作る。AI 下書きは便利だが、誤送信、返金実行、顧客情報の露出が怖く、管理者が許可しにくい。

With viyv

AI に任せる作業と、人間に戻す判断を分ける

CS agent が契約状況と FAQ を読み、回答文、社内メモ、返金可否の根拠を下書きする。メール送信、返金、契約変更は approval 待ちにして、人間が修正理由を残す。

Problem Solved

この workflow で解決できる問題

一次回答の作成時間を削りながら、返金と送信の責任境界を曖昧にしない。拒否理由が AI の再下書きに戻るため、現場のレビュー負荷も測れる。

Decision Moment

レビュー会議で見る判断材料

対象カテゴリ 30 件で一次回答時間、下書き修正率、SLA 影響、送信前 approval を見て、CS 部門展開へ進むかを決める。

Concrete Run

1 件の業務を、こう流す。

demo ではなく、現場が毎日扱う 1 件を起点にします。入力、AI の作業、人間に戻す判断、 残す成果物を分けると、検証の範囲が曖昧になりません。

Input

現場が持ち込むもの

問い合わせ一次回答、返金可否確認、契約変更依頼、障害影響調査。 を対象に、担当者、対象画面、社内 tool、AI に渡してよい情報を 1 つの範囲に固定します。

AI Work

AI に任せる作業

Agent Foundry で CS 調査 agent を定義する。Browser がログイン済み admin とチケット画面を read-only で参照する。AI が回答文、社内メモ、返金可否の根拠を下書きする

Human Gate

人間が止める判断

メール / チケット送信 / 返金実行 / 契約変更 / 登録情報変更

Output

残す成果物

回答下書き / 社内調査メモ / 返金判断メモ / 拒否理由

Operator Runbook

担当者が触る場所と、止める場所を分ける。

現場の操作を増やさず、AI の下書きと確認メモを使います。責任が残る操作は approval に戻し、失敗時の扱いも検証条件に入れます。

担当者の操作
  • チケット ID と顧客の要望を AI に渡す
  • AI が契約状況、FAQ、過去対応を確認した要約を見る
  • 回答文を修正し、送信前 approval で最終確認する
人間に戻す判断
  • メール / チケット送信
  • 返金実行
  • 契約変更 / 登録情報変更
失敗時の止め方
  • 回答根拠が不足している場合は送信せず調査メモに戻す
  • 返金条件が曖昧な場合は承認者に escalate する
  • 顧客情報が mask されない場合は AI 呼び出しを拒否する
検証合格条件
  • 対象カテゴリで一次回答時間を比較できる
  • 送信と返金が全件 approval 待ちになる
  • 拒否理由が AI の再下書きに反映される

Evidence Packet

検証の証拠を、判断材料に変える。

利用前に「AI が便利だった」ではなく、業務効果、統制、責任境界、展開条件を並べます。

業務範囲

CS 回答 / 返金判断 を 1 workflow として、owner は CS Ops、サポート、業務企画 に置きます。

測る効果

現場指標: 一次回答時間、下書き修正率、SLA 影響

見る統制

統制指標: 送信 / 返金 approval、顧客情報 mask、拒否理由

判断材料

導入判断: CS 品質を落とさず、責任境界を人間へ戻せるか

Stakeholder Review

社内の誰に、何を説明できるか。

業務部門、情シス、セキュリティ、管理部門が見る論点を分け、検証 の受け入れ条件に変えます。

業務責任者

現場のどの作業が短くなり、どの判断は人間に残るか。

回答

チケット ID と顧客の要望を AI に渡す / AI が契約状況、FAQ、過去対応を確認した要約を見る / 回答文を修正し、送信前 approval で最終確認する を日次運用に置き、メール / チケット送信 / 返金実行 / 契約変更 / 登録情報変更 は承認待ちに戻します。

見る証拠

一次回答時間 / 送信前 approval

情シス / AI platform

既存画面、社内 API、AI client の境界を説明できるか。

回答

viyv Agent Foundry / viyv Browser / viyv DB を使い、admin read-only / 送信 / 返金 HITL / 電話番号 mask を最初の境界にします。

見る証拠

送信前 approval / 拒否理由 / 問い合わせ履歴の再利用

セキュリティ / 法務

AI に渡らない情報、止まる操作、失敗時の扱いは明確か。

回答

admin read-only / 送信 / 返金 HITL / 電話番号 mask / agent version を検証の統制として固定し、失敗時は 回答根拠が不足している場合は送信せず調査メモに戻す。

見る証拠

送信と返金が全件 approval 待ちになる / 拒否理由が AI の再下書きに反映される

管理部門 / 経営

判断に進む条件と、広げる前の保留条件は何か。

回答

導入判断: CS 品質を落とさず、責任境界を人間へ戻せるか

見る証拠

対象カテゴリで一次回答時間を比較できる / 送信と返金が全件 approval 待ちになる / 拒否理由が AI の再下書きに反映される

Next Step

CS 回答 / 返金判断 の検証範囲を決める。

対象画面、社内 tool、人間に戻す判断、判断材料を 30 日の検証計画に落とします。