mcpField
C
customer-support-verification

customer-support-verification

github.com/akillnessその他5356 回インストール今日更新
リポジトリ

customer-support-verification について

SaaSサポート案件の最終確認に使うスキルです。担当者が案件を閉じる前に、証拠、承認、顧客への連絡、操作後の状態を確認できます。

主な機能

  1. 01証拠と操作のケース台帳
  2. 02PASS/FAIL/UNKNOWNの確認
  3. 03アカウントと正規スレッドの照合
  4. 04金銭・変更操作の承認確認
  5. 05送信・アーカイブ・終了の証明
  6. 06請求・アクセス別の確認項目

活用シーン

  1. 01終了前のアカウントアクセス修復確認
  2. 02解約・返金の承認と結果の確認
  3. 03メールスレッドのアーカイブ前の送信確認
  4. 04Trustpilot招待の適格性判断

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/akillness/jeo-skills --skill customer-support-verification

インストール後、Claude Code で/customer-support-verificationを入力して読み込まれたか確認します。

同梱ファイルSKILL.toonagents/openai.yaml

詳細

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

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

このスキルを使用するタイミング

  • SaaS サポートのトリアージ、アカウント/アクセス、または非対応プラットフォームへの回答について、下書き、送信、アーカイブの完了を報告する前。
  • 重複ケース、解決確認への了承ケース、または肯定的な確認ケースをクローズし、Trustpilot レビューの依頼が適格か判断するとき。
  • 解約、支払い失敗による解約、返金、または誤った更新への対応の前後に、金銭面の承認と事後の読み戻しを検証するとき。
  • 外部状態を変更する前に、アカウントと正規スレッドの照合、権限、変更承認を検証するとき。
  • 顧客に表示される送信(正確な宛先、件名、本文、SENT 状態)またはスレッド全体の Gmail アーカイブを確認する前。
  • サポートシナリオ自体の実行には使用しません。まず handle-saas-account-cases または handle-saas-billing-cases を読み込み、その後、このスキルを最終確認ゲートとしてのみ使用します。

ケース台帳を作成する

以下を収集します。

  • 選択したシナリオのフローと、最新の完全な顧客との会話。
  • 信頼できる製品ポリシー、アカウント、請求、メールの情報源。
  • 正規化した顧客識別情報、および該当する正式なアカウント、請求、サブスクリプション、請求書、取引、スレッド、メッセージ、下書きの 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への招待を許可するのは、問題が完全に解決した、異議のないアカウント/アクセスまたは製品サポートの成功に限ります。確認された製品に対して、公式に設定されたプロフィールとリンクが検証済みであり、捏造されておらず、別の製品から流用されていないことを確認します。
  • 招待で評価を求めておらず、インセンティブを提示せず、圧力をかけておらず、送信について明確な承認が得られていることを確認します。ゲートを1つでも通過できない場合、クローズの返信から招待を省略します。
  • 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にするために必要なことを正確に記載します。

参照

コメント