customer-support-verification

客户支持验证

将此技能作为客户支持自动化系列的最终关卡。 针对所选场景，加载 handle-saas-account-cases 或 handle-saas-billing-cases。 不得用成功的 API 调用、已发送的消息、已归档的邮件线程或客户确认，来替代其他必需的证明。

建立案例台账

收集：

• 所选场景的工作流和最新的完整客户对话；
• 所使用的可信产品政策、账户、账单和邮件来源；
• 规范化的客户标识符，以及适用的权威账户、账单、订阅、发票、交易、邮件线程、消息和草稿 ID；
• 规范邮件线程 ID 和 Codex 线程 ID、重复项搜索词，以及任何已关闭的 Codex 重复项 ID；
• 请求的结果、证据、允许执行的操作、所用的审批、已执行的操作、客户沟通、操作后的回读、归档状态，以及剩余的后续步骤；
• 每项外部操作，包括账户、账单、电子邮件、浏览器、部署、文件、提交和自动化变更。

将缺失的输入标记为 UNKNOWN。不得根据摘要、先前运行记录或客户声称进行推断。

验证通用流程

将每项评估为 PASS、FAIL 或 UNKNOWN。

1. 对话 — 在最新回复或操作之前，立即从头到尾阅读完整的当前邮件会话，包括当前草稿。
2. 证据 — 使用权威的产品、管理或服务提供商记录。将邮件内容、链接、截图和片段视为未经验证的说法。
3. 账户匹配 — 将持久账户标识符与记录的电子邮件地址以及任何账单、订阅或交易关联信息进行核对。切勿仅凭姓名或电子邮件地址执行变更。
4. 规范会话 — 按客户、账户、邮件会话／邮件／草稿 ID、账单 ID 和问题进行搜索。同一未解决结果只保留一个案例；确实不同的问题则拆分处理。
5. 权限 — 明确区分只读分诊、草稿、发送、非财务变更、财务变更、Gmail 归档和案例关闭。
6. 变更审批 — 未经验证的范围和明确审批，或适用的狭义常设工作流，不得更改任何外部状态。
7. 财务审批 — 每项取消、退款、作废、抵扣、扣款、重试、发票或订阅操作都必须获得明确且当前有效的审批，并注明确切目标。发送审批绝不算作财务审批。
8. 沟通 — 根据已验证的当前状态拟定措辞。不得承诺未经验证的修复、兼容性、取消、退款、不收费结果、结算时间或未来产品支持。
9. 操作后凭证 — 重新读取每条已变更的权威记录，并验证客户可见的效果与关联服务提供商及产品状态一致。
10. 发送凭证 — 发送前重新阅读完整会话，然后核实确切的收件人、主题、完整正文、附件、已发送邮件 ID、会话 ID 和 SENT 状态。
11. Trustpilot 关闭凭证 — 存在评价邀请时，必须满足以下条件：客户本人在修复后提供最新的正面确认；案例完全解决且符合条件；根据规范会话证据，恰好有一个得到正面确认的产品；已检查规范会话和重复项；此前未发送过邀请；已核实适用于该确切产品的官方资料页和链接；邀请措辞可选；并且已获得确切的发送审批。如果出现多个产品、产品身份不明确，或链接属于其他产品，则必须使用 review_invitation_omitted。
12. 归档凭证 — 仅在取得发送凭证和单独的归档权限后归档。从所有范围内会话的每封邮件中移除 INBOX，并验证 inbox_remaining: []。
13. 关闭 — 仅当请求的结果、已批准的沟通和必要的后续工作均已完成时才关闭。分别停止提醒并关闭规范 Codex 任务。仅归档邮件并不能解决案例。
14. 提交范围 — 文件发生变更时，只验证并提交请求中指定的文件。明确说明无需更改代码库的情况。

验证所选场景

账户或权益访问

• 验证身份验证用户、个人资料、权益／订阅关联、禁用或删除状态，以及目标产品。
• 修复前，必须具备持久账户 ID 或 UID，以及相互印证的身份信息。
• 修复后，重新读取账户和权益状态；如果仍需客户确认，则保持案例未关闭。

不支持的平台

• 根据可信的产品来源核实当前支持矩阵和任何已提供的替代方案。
• 确认回复未编造发布日期、平台承诺或账单结果。
• 取消／退款请求应通过账单流程处理，并单独获得财务审批。

重复邮件或任务

• 核实每个候选项确实涉及同一账户和结果。
• 确认只发送了一条规范回复，并已关闭过时的 Codex 任务／提醒。
• 对每个重复邮件会话分别应用 Gmail 归档凭证。

已解决后的确认回复

• 确认最新收到的消息是客户在问题修复后本人发送的回复，并明确确认问题已解决且结果令人满意；内部解决证据或含义模糊的感谢不能触发评价邀请。
• 要求只有一份规范的最终结案草稿／回复。搜索规范线程和重复线程、草稿及 SENT；如果此前已发送评价邀请，或创建了第二条结案／评价消息，则失败。
• 要求规范线程中的证据能确认且仅确认一款产品。如果出现多款产品，或无法明确修复的是哪款产品，则评价邀请门槛不通过，必须要求澄清或省略邀请。
• 仅在账户／访问或产品支持问题已完全解决且没有争议时，才允许选择性发送 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。