カスタマーサポートの共有メールボックスに届く製品のクレームを、内容と緊急度で分けて担当チームに振り分け、初回の返信の下書きを付ける

処理の起点を決める

共有メールボックスに新しいメールが届いたことを起点にします。 トリガーの Folder は受信トレイ、Include Attachments は「いいえ」にします。添付の写真はこの段では使わないので、中身を受け取ってフローを重くしません。

トリガーの性質を2つ押さえておきます。 1つ目は、受信日時で判定するため、別のフォルダに移したメールでは動かないことです。人が先に手でフォルダへ移すと、そのメールはフローを通りません。導入後は、受信トレイのメールを人が手で移さない運用にします。 2つ目は、共有メールボックスへの権限です。フローの接続に使うアカウントに、共有メールボックスへのフルアクセスを付けます。

フィルタは差出人で除外を作ります。 自社の通販のシステムからの注文確認、配送業者からの通知などは、別のフローか受信トレイのルールで先に別フォルダへ送ります。クレームのフローには、お客様からのメールだけが入るようにします。

入力データを集める

質を決めるのは、安全の語の一覧です。 お客様は「やけど」と書かずに「熱くて手が赤くなった」と書き、「発火」と書かずに「パチッと光って黒くなった」と書きます。品質保証の担当が、過去のクレームから言い換えを拾って一覧に足します。 一覧は広めに取り、拾いすぎを恐れません。品質保証が1件余計に読む手間は、1件見落とす重さに比べれば小さいからです。

製品の一覧は、型番の書き間違いを吸収するために持ちます。 お客様は型番を正確に書かず、「白いケトル」「去年買ったトースター」と書きます。AIには一覧の名前から選ばせ、選べなければ「不明」にさせます。

データの取得方法を決める

同じお客様の直近の記録は、AIに渡す前に引きます。 直近7日に同じ差出人の記録があれば、分類の結果にかかわらず、前の担当に寄せます。 第3章の（d）への答えです。

AIへ渡す前に整形する

1. 引用部分を落とす … 返信の形で届いたメールは、過去のやり取りが下に続きます。「-----Original Message-----」「〜wrote:」以降を落とします
2. 署名の電話番号と住所を落とす … 分類にも下書きにも要りません。対応の記録にだけ残します
3. 安全の語の照合 … 落とす前の件名と本文の全文を、一覧の語で照合します。照合は前処理の段で、AIより先に行います
4. 本文が長すぎるときは切らずに印を付ける … 経緯が長いメールは、そのまま渡し、記録に「長文」の印を付けます

3番目を引用部分を落とす前に行うのは、引用の中にけがの記載があることがあるからです。 2通目のメールで、1通目の「やけどをした」が引用として残っていることがあります。拾いすぎてよい照合は、全文に対して行います。

AIに処理させる

させるのは、本文から項目を拾って分類し、根拠の文を写すことです。 緊急度とチームは、AIの結果をもとに規則で決めます。

安全に関わる記載は、迷えば true にさせます。 規則の照合で拾えなかった言い回しを、AIが補う位置づけです。AIが true にしたものも、規則で拾ったものと同じく品質保証に知らせます。 逆に、規則で拾ったものをAIが false と返しても取り消しません。

使用の継続を拾うのは、品質保証が最初に伝えることが決まっているからです。 発煙の記載があって「今も使っている」なら、品質保証の担当は使用を止めてもらう連絡を最初にします。

1行目は、この構成でいちばん大事な線引きです。 消費者庁の資料は、重大製品事故を死亡、治療に要する期間が30日以上の負傷・疾病、後遺障害、一酸化炭素中毒、消防が火災と認定した火災などとしています。メールの文面からは、治療の期間も消防の認定も分かりません。AIが判断できる材料が無いので、判断させずに品質保証へ届けます。

指示内容を固定する

1つ目のプロンプト（分類）の指示：

あなたは家電メーカーのカスタマーサポートで、製品のクレームのメールを
読み分ける担当です。本文に書かれていることだけを使ってください。
推測で埋めないでください。

【不具合の種類】下の定義から1つ選んでください。迷う場合は unclassified。
- 初期不良：届いた直後・初回の使用から動かない、動作がおかしい
- 配送の破損：箱や本体が届いた時点で壊れていた、へこんでいた
- 使用中の故障：しばらく使ってから動かない、止まる、漏れる
- 部品の欠品：付属品や部品が入っていない
- 使い方の質問：操作や手入れの方法を尋ねている
- 安全：けが、やけど、煙、発火、火花、焦げ、溶け、異常な発熱やにおい

【安全に関わる記載】
- けが・発煙・発火・異常な発熱・焦げくさいにおいの記載が、本文の
  どこかに1つでもあれば safety_flag を true にしてください。
- 迷う場合も true にしてください。
- その文を safety_evidence にそのまま写してください。
- 重大な事故かどうか、原因が製品にあるかどうかを書かないでください。

【厳守事項】
- product は製品の一覧の名前から選んでください。選べなければ unknown。
- お客様の使い方が悪かったと受け取れることを書かないでください。
- still_in_use には、お客様が今も使っているかの記載を写してください。
  書かれていなければ not_stated。
- evidence に、種類を選んだ根拠の文を本文からそのまま写してください。
- Don't include JSON markdown in your answer.

【製品の一覧】{product_list}
【件名】{subject}
【本文】{body}

「Don't include JSON markdown in your answer」を最後に置くのは、JSON が作れないときの対処として案内されている一文だからです。 日本語の指示の中に英語の一文が混ざりますが、そのまま入れます。

2つ目のプロンプト（初回の返信の下書き）の指示：

家電メーカーのお客様窓口から、製品についてご連絡をくださった方への
最初の返信を書いてください。次のことだけを書いてください。
- ご連絡のお礼と、ご不便をおかけしていることへのお詫び（下の文のとおり）
- 受け付けた内容の確認（製品名と、お客様が書いた症状の要点）
- 確認のためにお願いしたいこと（下の一覧のとおり。足さない）
- 担当のチームから改めて連絡すること
書かないこと：原因、交換・返金・無償修理に応じるかどうか、
お客様の使い方についての指摘、修理にかかる日数。
【お詫びの文】{apology_text}　【お願いしたいこと】{requests_for_team}
【製品】{product}　【症状の根拠の文】{evidence}　【お客様の氏名】{name}

「お願いしたいこと」は、チームごとに決めた一覧を外から渡します。 配送の破損なら「箱と本体の写真」、使用中の故障なら「型番と購入日の分かるもの」。お詫びの文も品質保証と決めた文を渡し、AIには並べさせるだけにします。 交換や返金に触れた下書きが承認の画面に出ても、当番がそのまま承認してしまう余地を減らすためです。

出力形式を固定する

1つ目のプロンプトの出力は、Custom の JSON 形式として次の例で固定します。

{
  "category": "使用中の故障",
  "product": "電気ケトル KT-120",
  "model_no": "KT-120",
  "purchase_channel": "量販店 | 自社の通販 | その他 | not_stated",
  "safety_flag": false,
  "safety_evidence": "",
  "still_in_use": "not_stated",
  "evidence": "2か月ほど使っていたら、電源ランプが点かなくなりました。"
}

Custom にして保存するのは、テストのたびに形が変わらないようにするためです。 Auto detected のままだと、テストで出た形が保存のたびに記録され、後段の項目の参照が外れることがあります。 キーの無い配列は定義できないので、項目はすべてキー付きで並べます。

項目に分けて受け取る理由は、緊急度の規則にそのまま使えることです。

S の条件が2つの「または」で、どちらかに当たれば S にするのは、規則とAIのどちらにも取り消させないためです。 規則が拾えなかったものをAIが拾い、AIが見落としたものを規則が拾います。

システムへ連携する

返信は、承認された文面だけを Reply to email (V3) で送ります。 Original Mailbox Address に共有メールボックスを指定し、お客様には担当者個人ではなく窓口のアドレスから返事が届きます。 承認されなかった下書きは送らず、記録に「却下」と残して当番が手で返信します。

Teams への投稿には制約があります。 投稿できるメッセージは約28KBまでで、プライベートチャネルには投稿できません。 品質保証のチャネルは標準のチャネルにします。投稿には、Teams 管理センターで Workflows のアプリが許可されている必要があります。

Outlook のコネクタの回数の上限は、接続ごとに60秒あたり300回です。 月900件で1件に数回の呼び出しなら収まりますが、届いたメールの一斉の再処理をするときは間隔を空けます。

人が確認する

1. S の連絡を受けた品質保証の担当 … メールを読み、お客様に直接連絡します。事故の内容と、事故を知った日を記録します
2. 承認の依頼を受けたチームの当番 … 分類と根拠の文を見て、自分のチームの案件かを確かめ、下書きを直して承認します
3. 担当違いの差し戻し … 当番が却下の理由に「担当違い」と書くと、記録の担当を空にしてリーダーに戻します
4. リーダーの見直し … unclassified と担当違いのものを毎日見て、担当を決めます

1番目の「事故を知った日」の記録を省かないでください。 消費者庁の資料では、報告の期限は知った日を含めて10日以内とされ、10日目が休日のときは翌日が期限とされています。共有メールボックスに届いた日時と、品質保証が読んだ日時の両方を記録に残し、どちらを起算日とするかは品質保証と法務が決めます。

目標は、900件をならして1件3分です。 分類が正しく下書きもそのまま承認できる案件は1〜2分、担当違いと下書きの直しは数分かかります。

例外に対処する

最後の行は、S の連絡を1つの経路に頼らないためです。 Workflows のアプリの許可が外れた、チャネルを作り直した、といったことで投稿は失敗します。S だけは、Teams とメールの2つの経路で届けます。

記録を残す

• メールのメッセージID、受信日時、差出人、件名
• 安全の語の照合の結果（当たった語）と、AIが返した JSON の全文
• 緊急度と、それを決めた規則の条件
• 承認の結果（承認・却下）と、承認者が直した後の文面
• 品質保証が S を読んだ日時と、お客様に連絡した日時
• 当番が分類を直した記録 … どの種類からどの種類へ直したか

5つ目は、報告の期限を後から説明するための記録です。 いつ届き、いつ品質保証が知り、いつ連絡したかが並んでいれば、社内のどこで時間がかかったかが分かります。

最後の行が、定義と語の一覧を育てる材料です。 直された分類と、S に入らなかったが後で安全に関わると分かった案件を月に一度数え、言い回しを語の一覧と定義に足します。