工单拦截器

快速开始

转发或粘贴客户邮件——Claude 从 PayPal 拉取订单状态，在 HubSpot 中查找客户，并以所有者的语气起草回复。如果需要退款，它将准备好详细信息并等待明确批准后再执行任何操作。

用户："回复这位客户" [转发邮件]
→ 从邮件线程中提取客户邮箱 + 问题
→ 拉取 PayPal 交易状态
→ 拉取 HubSpot 联系人历史
→ 以所有者的语气起草回复
→ 所有者批准草稿 → 发送或编排
→ 如果需要退款：批准提示 → 所有者确认 → 执行

工作流程

1. 阅读客户消息。 接受转发的 Gmail 邮件线程或粘贴的文本。提取：客户邮箱地址、姓名、订单或交易 ID（如有）、以及核心问题——退款请求、订单状态查询或一般投诉。如果存在多个问题，按出现顺序逐一处理。

2. 从 PayPal 拉取订单状态。 按客户邮箱或交易 ID 搜索 PayPal 交易。获取：金额、日期、状态、以及是否已发放退款。如果 PayPal 未连接，在草稿中注明并继续。如果没有匹配的交易，标记该问题——不要猜测匹配项。

   • PayPal 速率限制： 如果客户提供了交易 ID，使用该 ID——单记录查找完全避免限流。如果按邮箱搜索，使用7天窗口（而非30天）。PayPal 的交易列表端点在宽日期范围查询上会严重限流；如果窗口太宽，同一会话中连续处理工单将触发此限制。
   • 如果 Intercom 已连接，检查此客户是否有未结的支持工单。
   • 如果 Square 已连接，检查 Square 交易历史作为次要来源。
   • 如果匹配到多个交易，全部列出并让所有者选择哪一个适用，然后再起草。

3. 从 HubSpot 拉取客户历史。 按邮箱地址搜索联系人。获取：生命周期阶段、备注、未结交易和近期活动。如果不存在联系人，注明并在回复发送后主动提出创建——不要在回复工作流中创建。

4. 起草回复。 以所有者的写作语气撰写。根据问题类型调整语气：

   • 退款请求 → 共情、清晰、行动导向
   • 订单状态查询 → 事实性、安抚性
   • 一般投诉 → 承认、解释、提供解决方案 在草稿中内联标记任何数据缺口，使用括号注释（例如，[注：未找到 PayPal 交易——发送前请核实订单 ID]），以便所有者在发送前看到缺口。已完成示例请参见 reference/examples/respond-refund-request.md。常见陷阱请参见 reference/gotchas.md。

5. 审批关口 — 所有者审阅草稿。 呈现完整草稿。在所有者的审批通过前，不要发送或编排。所有者可以在审批前自由编辑。

6. 审批关口 — 退款发放。 如果退款是合理的，在所有者的审批通过草稿后显示专门的确认提示：

   "向 [客户名称]（[邮箱]）发放交易 [ID] 退款 $[金额]？回复 Y 继续。"

   等待明确确认。如果所有者的回复不是明确的肯定，停止并询问他们希望怎么做。

7. 发送或编排回复。 在草稿获批后，询问所有者：立即通过 Gmail 发送，还是保存为草稿？执行其选择。然后将交互记录为 HubSpot 联系人时间轴上的备注。

8. 报告。 一段简短的总结：回复已发送或已编排、退款已发放或未发放、HubSpot 备注已记录。

审批关口

• 未经所有者明确确认，切勿发放 PayPal 退款 — 始终在执行前显示金额、客户名称、邮箱和交易 ID。
• 未经所有者审阅，切勿发送回复。 始终先呈现完整草稿。
• 切勿在回复流程中创建 HubSpot 联系人。 主动提出在之后创建。
• 切勿自动选择 PayPal 交易。 如果多个匹配，全部列出让所有者选择。
• 切勿编造订单详情。 如果 PayPal 没有记录，在草稿中内联说明——不要编造状态。

参考

• reference/gotchas.md — 语气、PayPal 查找和模糊退款场景的正确/错误模式
• reference/examples/respond-refund-request.md — 已完成示例：找到 PayPal 交易时的退款请求