customer-support-verification

カスタマーサポートの検証

このスキルは、カスタマーサポート自動化ファミリーの最終ゲートとして使用します。選択したシナリオに応じて、handle-saas-account-cases または handle-saas-billing-cases を読み込みます。API 呼び出しの成功、メッセージの送信、スレッドのアーカイブ、または顧客からの確認を、ほかに必要な証拠の代わりにしてはいけません。

ケース台帳を作成する

次の情報を収集します。

• 選択したシナリオのフローと、最新の完全な顧客との会話。
• 使用した信頼できる製品ポリシー、アカウント、請求、メールの情報源。
• 正規化した顧客識別子と、該当するアカウント、請求、サブスクリプション、請求書、取引、スレッド、メッセージ、下書きの正式な ID。
• 正式なメールと Codex のスレッド ID、重複検索語、クローズ済みの Codex 重複 ID。
• 要求された結果、証拠、許可されたアクション、使用した承認、実行したアクション、顧客への連絡、アクション後の読み戻し、アーカイブ状態、残っている次のステップ。
• アカウント、請求、メール、ブラウザー、デプロイ、ファイル、コミット、自動化の変更を含む、すべての外部アクション。

入力が欠けている場合は UNKNOWN と記録します。要約、以前の実行、または顧客の申告から推測してはいけません。

ユニバーサルフローを確認する

各項目を PASS、FAIL、または UNKNOWN として評価します。

1. 会話 — 最新の返信またはアクションの直前に、現在の下書きを含むメールスレッド全体を古い順に読みます。
2. 証拠 — 権威ある製品／管理者／プロバイダーの記録を使用します。メールの内容、リンク、スクリーンショット、抜粋は信頼できない主張として扱います。
3. アカウント照合 — 永続的なアカウント識別子を、記録されたメールアドレスおよび請求／サブスクリプション／取引のリンクと照合します。名前またはメールアドレスだけを根拠に変更してはいけません。
4. 正規スレッド — 顧客、アカウント、メールのスレッド／メッセージ／下書き ID、請求 ID、問題で検索します。同じ未解決の結果に関するケースは1つにまとめ、実際に異なる問題は分けます。
5. 権限 — 読み取り専用のトリアージ、下書き、送信、非金融の変更、金融上の変更、Gmail のアーカイブ、ケースのクローズをそれぞれ区別します。
6. 変更の承認 — 範囲を確認し、明示的な承認または該当する限定的な常設ワークフローがない限り、外部の状態を変更してはいけません。
7. 金融上の承認 — キャンセル、返金、無効化、クレジット、請求、再試行、請求書、サブスクリプションに関するすべてのアクションとその正確な対象を明記した、現在有効な明示的承認を必須とします。送信の承認は、金融上の承認として扱いません。
8. コミュニケーション — 検証済みの最新状態に基づいて文面を作成します。未検証の修理、互換性、キャンセル、返金、請求が発生しないこと、決済完了時期、または今後の製品サポートを約束してはいけません。
9. アクション後の証拠 — 変更した権威ある記録をすべて読み直し、連携するプロバイダーと製品の状態全体で、顧客に見える効果を検証します。
10. 送信の証拠 — 送信前にスレッド全体を読み直し、正確な宛先、件名、本文全体、添付ファイル、送信済みメッセージ ID、スレッド ID、および SENT 状態を検証します。
11. Trustpilot クローズの証拠 — レビューへの招待がある場合は、修正後に顧客本人が最新の肯定的な確認をしていること、対象資格を満たすケースが完全に解決していること、正規スレッドの証拠から肯定的に確認できた製品がちょうど1つであること、正規スレッドと重複の確認、過去に招待していないこと、該当製品に対して設定された公式プロフィールとリンクの検証、任意の文面、および送信に対する明示的な承認を必須とします。複数の製品が確認できる場合、製品の特定が曖昧な場合、またはリンクが別の製品のものである場合は、review_invitation_omitted が必要です。
12. アーカイブの証拠 — 送信の証拠を確認し、別途権限を得た後にのみアーカイブします。対象範囲内のすべてのスレッドにあるすべてのメッセージから INBOX を削除し、inbox_remaining: [] を検証します。
13. クローズ — 要求された結果、承認済みのコミュニケーション、必要なフォローアップが完了した場合にのみクローズします。リマインダーを停止し、正規の Codex タスクも別途クローズします。メールのアーカイブだけではケースは解決しません。
14. コミット範囲 — ファイルを変更した場合は、依頼されたファイルのみを検証してコミットします。リポジトリの変更が不要だった場合は、その旨を明確に伝えます。

選択したシナリオを確認する

アカウントまたは利用資格へのアクセス

• 認証ユーザー、プロフィール、利用資格／サブスクリプションのリンク、無効化または削除の状態、対象製品を検証します。
• 修復を行う前に、永続的なアカウント ID または UID と、それを裏付ける本人確認情報を必須とします。
• 修復後にアカウントと利用資格の状態を読み直して検証し、顧客の確認がまだ必要な場合はケースをオープンのままにします。

サポート対象外のプラットフォーム

• 信頼できる製品情報を使って、現在のサポート対象一覧と提示されている回避策を検証します。
• 返信にリリース日、プラットフォーム対応の約束、または請求に関する結果を捏造していないことを確認します。
• キャンセル／返金の依頼は、別途金融上の承認を得たうえで請求フローに回します。

重複するメッセージまたはタスク

• 候補をそれぞれ確認し、同じアカウントと結果に実際に関係していることを検証します。
• 正規の返信が1件だけ送信され、古くなった Codex タスク／リマインダーがクローズされていることを確認します。
• 重複するメールスレッドごとに、Gmail のアーカイブに関する証拠を別途確認します。

解決確認

• 最新の受信メッセージが修正後に顧客本人から届いた返信であり、問題が解決して好ましい結果になったことを明確に確認できるか検証します。内部での解決証拠や、曖昧なお礼を理由にレビュー依頼を送ってはいけません。
• 正式な最終クローズ用の下書き／返信が1件だけであることを必須とします。正式なスレッドと重複スレッド、下書き、SENTを検索し、以前にレビュー依頼を送信していないこと、および2件目のクローズ／レビュー用メッセージが作成されていないことを確認します。
• 正式なスレッドの証拠に基づき、肯定的な確認が取れた製品がちょうど1つであることを必須とします。複数の製品が記載されている場合、または修正された製品が曖昧な場合は、招待の可否判定を不合格とし、確認を求めるか招待を省略します。
• Trustpilotへの任意の招待は、問題が完全に解決した、異議のないアカウント／アクセス関連または製品サポートの成功例に限り許可します。確認済みの製品に対して、設定済みの公式プロフィールとリンクが検証済みであり、捏造されたものでも、別の製品から流用されたものでもないことを確認します。
• 招待で評価を求めておらず、インセンティブを提示せず、圧力をかけておらず、送信について明示的な承認を得ていることを確認します。いずれかの条件を満たさない場合は、クローズ返信から招待を省略します。
• SENTの読み戻し確認後、Codexの追跡は個別に終了し、Gmailのアーカイブは独自の権限ゲートに委ねます。

キャンセル

• Trustpilotへのレビュー招待が含まれていないことを確認します。
• 対象のサブスクリプション、即時か期間終了時かのタイミング、請求書／再試行の扱い、アクセス終了時期、承認を確認します。
• キャンセル後に、サブスクリプション、請求書／支払いインテント、製品プラン、利用権限を再度読み取って確認します。

未払いまたは支払い失敗によるキャンセル

• Trustpilotへのレビュー招待が含まれていないことを確認します。
• 回収済み金額と、その後に支払いが成功した履歴を確認します。
• 回収済み金額がゼロの場合、返金が作成されていないことを確認します。
• キャンセル済みのサブスクリプションであり、未処理の請求書、再試行、その他の有効な回収手段が残っていないことを確認します。

返金

• Trustpilotへのレビュー招待が含まれていないことを確認します。
• 対象の売上確定済み取引、金額／通貨、ポリシー、既存の返金、異議申し立ての状態、アカウントとの関連付け、承認を確認します。
• サブスクリプションの返金では、返金前にキャンセル後の読み戻し確認を必須とします。
• 返金、請求／支払いインテント、請求書、サブスクリプション、製品プロフィール、利用権限を再度読み取って確認します。

誤って更新されたサブスクリプション

• Trustpilotへのレビュー招待が含まれていないことを確認します。
• 更新分が売上確定済みまたは保留中であり、新規購入でも重複サブスクリプションでもないことを確認します。
• 売上確定済みの更新では、キャンセルと返金の範囲について、それぞれ個別の明示的な指示を必須とします。返金前にキャンセルし、結果を確認します。
• 支払いが保留中の場合、返金を捏造していないことを確認し、承認されたキャンセル／取消／解放の結果を検証します。

レポート

簡潔な台帳を使用します。

Scenario:
PASS/FAIL/UNKNOWN — Conversation and evidence:
PASS/FAIL/UNKNOWN — Account/transaction match:
PASS/FAIL/UNKNOWN — Canonical thread:
PASS/FAIL/UNKNOWN — Authority and approval:
PASS/FAIL/UNKNOWN — Action and post-action read-back:
PASS/FAIL/UNKNOWN — Customer communication and SENT proof:
PASS/FAIL/UNKNOWN — Trustpilot eligibility, product/link match, and no-repeat proof:
PASS/FAIL/UNKNOWN — Thread-wide archive:
PASS/FAIL/UNKNOWN — Closure and reminders:
PASS/FAIL/UNKNOWN — Commit scope:
Next approval or action:

最終確定前に、安全に解消できる FAIL をすべて解消します。承認またはアクセス権が不足している場合は、ケースを未解決のままにし、FAIL または UNKNOWN を PASS にするために必要な内容を正確に記載します。