客户沟通/支持场景下草拟专业客户回复并适配关系与情境

当需要回答产品问题、处理升级或故障、传递延迟或拒绝等坏消息、拒绝功能请求或回复账单问题时，用于生成专业客户回复草稿。

适用场景

解决思路

1. 当看到不熟悉的占位符或需要检查已连接工具时，查看 CONNECTORS.md。
2. 使用命令 `/draft-response <situation description>` 或 `/draft-response <context about the customer question, issue, or request>` 启动草拟。
3. 输入上下文示例：`/draft-response Acme Corp is asking when the new dashboard feature will ship`。
4. 输入上下文示例：`/draft-response Customer escalation — their integration has been down for 2 days`。
5. 输入上下文示例：`/draft-response Responding to a feature request we won't be building`。
6. 输入上下文示例：`/draft-response Customer hit a billing error and wants a resolution ASAP`。
7. 理解上下文：确定 Customer——沟通对象是谁，如可用则查找账户上下文。
8. 理解上下文：确定 Situation type——question、issue、escalation、announcement、negotiation、bad news、good news、follow-up。
9. 理解上下文：确定 Urgency——是否时间敏感、客户已等待多久。
10. 理解上下文：确定 Channel——email、support ticket、chat 或其他，并据此调整正式程度。
11. 理解上下文：确定 Relationship stage——新客户、既有客户、沮丧/已升级。
12. 理解上下文：确定 Stakeholder level——最终用户、经理、高管、技术、业务。
13. 研究上下文：从 ~~email 查找与该客户就该主题的先前通信。
14. 研究上下文：从 ~~email 查找先前共享的任何承诺或时间线。
15. 研究上下文：从 ~~email 了解现有线程的语气和风格。
16. 研究上下文：从 ~~chat 查找关于该客户或主题的内部讨论。
17. 研究上下文：从 ~~chat 查找产品、工程或领导层的指导。
18. 研究上下文：从 ~~chat 查找类似情况及其处理方式。
19. 研究上下文：从 ~~CRM（若已连接）获取账户详情和套餐级别。
20. 研究上下文：从 ~~CRM（若已连接）获取联系信息和关键利益相关者。
21. 研究上下文：从 ~~CRM（若已连接）获取先前升级或敏感问题。
22. 研究上下文：从 ~~support platform（若已连接）获取相关工单及其解决方案。
23. 研究上下文：从 ~~support platform（若已连接）获取已知问题或临时解决方案。
24. 研究上下文：从 ~~support platform（若已连接）获取 SLA 状态和响应时间承诺。
25. 研究上下文：从 ~~knowledge base 获取可引用的官方文档或帮助文章。
26. 研究上下文：从 ~~knowledge base 获取可分享的产品路线图信息。
27. 研究上下文：从 ~~knowledge base 获取政策或流程文档。
28. 生成草稿：输出 `## Draft Response`，包含 `**To:** [Customer contact name]`。
29. 生成草稿：包含 `**Re:** [Subject/topic]`。
30. 生成草稿：包含 `**Channel:** [Email / Ticket / Chat]`。
31. 生成草稿：包含 `**Tone:** [Empathetic / Professional / Technical / Celebratory / Candid]`。
32. 生成草稿：正文后包含内部 `### Notes for You (internal — do not send)`。
33. 内部备注包含 `**Why this approach:** [Rationale for tone and content choices]`。
34. 内部备注包含 `**Things to verify:** [Any facts or commitments to confirm before sending]`。
35. 内部备注包含 `**Risk factors:** [Anything sensitive about this response]`。
36. 内部备注包含 `**Follow-up needed:** [Actions to take after sending]`。
37. 内部备注包含 `**Escalation note:** [If this should be reviewed by someone else first]`。
38. 运行质量检查：确认语气匹配情况和关系。
39. 运行质量检查：不做出超出授权的承诺。
40. 运行质量检查：不分享不应对外分享的产品路线图细节。
41. 运行质量检查：对先前对话的引用准确。
42. 运行质量检查：有清晰的下一步和负责人。
43. 运行质量检查：适合利益相关者级别（对高管不过于技术，对工程师不过于模糊）。
44. 运行质量检查：长度适合渠道（chat 更短，email 更完整）。
45. 提供迭代：询问是否调整语气（更正式、更随意、更有同理心、更直接）。
46. 提供迭代：询问是否添加或删除具体要点。
47. 提供迭代：询问是否缩短/加长。
48. 提供迭代：询问是否为不同利益相关者起草版本。
49. 提供迭代：询问是否同时起草内部升级说明。
50. 提供迭代：询问是否准备在 [X days] 后无响应时的跟进消息。
51. 核心原则：以同理心开头，在跳到解决方案前承认客户处境。
52. 核心原则：直接，开门见山，bottom-line-up-front，因为客户很忙。
53. 核心原则：诚实，绝不过度承诺、误导或用行话隐藏坏消息。
54. 核心原则：具体，使用具体细节、时间线和姓名，避免模糊语言。
55. 核心原则：承担责任，适当使用「我们」而非「系统」或「流程」。
56. 核心原则：闭环，每个回复都有清晰下一步或行动号召。
57. 核心原则：匹配对方情绪，如果对方沮丧先表达同理心，如果对方兴奋则热情回应。
58. 响应结构：先写 Acknowledgment / Context（1-2 句），承认对方所说/所问/所经历，并表明理解其处境。
59. 响应结构：写 Core Message（1-3 段），传递主要信息、答案或更新，具体且包含所需细节。
60. 响应结构：写 Next Steps（1-3 个 bullet），说明你将做什么及何时做、他们需要做什么（如有）、他们下次何时收到你的消息。
61. 响应结构：写 Closing（1 句），温暖但专业地结束，并重申如有需要可联系你。
62. 长度指南：Chat/IM 用 1-4 句，立即切入重点。
63. 长度指南：Support ticket response 用 1-3 个短段落，结构化且可扫读。
64. 长度指南：Email 最多 3-5 段，尊重对方收件箱。
65. 长度指南：Escalation response 按需足够详尽，但用标题良好组织。
66. 长度指南：Executive communication 越短越好，最多 2-3 段，数据驱动。
67. 语气：好消息/胜利用 Celebratory——热情、温暖、祝贺、面向未来。
68. 语气：常规更新用 Professional——清晰、简洁、信息充分、友好。
69. 语气：技术回复用 Precise——准确、详细、结构化、耐心。
70. 语气：延迟交付用 Accountable——诚实、歉意、行动导向、具体。
71. 语气：坏消息用 Candid——直接、有同理心、解决方案导向、尊重。
72. 语气：问题/故障用 Urgent——即时、透明、可行动、令人安心。
73. 语气：升级用 Executive——镇定、承担责任、给出计划、自信。
74. 语气：账单/账户用 Precise——清晰、事实、有同理心、以解决为中心。
75. 关系阶段：新客户（0-3 个月）更正式专业，提供额外背景和解释（不要假设对方懂），主动提供帮助和资源，通过可靠和响应建立信任。
76. 关系阶段：既有客户（3+ 个月）温暖协作，可引用共同历史和先前对话，更直接高效，展现对其目标和优先事项的了解。
77. 关系阶段：沮丧或已升级客户给予额外同理心和承认，响应时间有紧迫感，给出具体承诺的行动计划，缩短反馈循环。
78. 写作 DO：使用主动语态，如「We'll investigate」而非「This will be investigated」。
79. 写作 DO：个人承诺用「I」，团队承诺用「we」。
80. 写作 DO：分配行动时点名具体人员，如「Sarah from our engineering team will...」。
81. 写作 DO：使用客户的术语，而非内部行话。
82. 写作 DO：包含具体日期和时间，而非相对说法，如「by Friday January 24」而非「in a few days」。
83. 写作 DO：用标题或 bullet 拆分长回复。
84. 写作 DON'T：不要使用企业行话或 buzzwords（如「synergy」「leverage」「paradigm shift」）。
85. 写作 DON'T：不要把责任推给其他团队、系统或流程。
86. 写作 DON'T：不要用被动语态避免承担责任（如「Mistakes were made」）。
87. 写作 DON'T：不要加入削弱信心的不必要 caveats 或 hedging。
88. 写作 DON'T：不要不必要地 CC，只包括需要参与对话的人。
89. 写作 DON'T：不要过度使用感叹号（每封邮件最多一个，若使用）。
90. 场景：回答产品问题时，先给直接答案，提供相关文档链接，必要时提出联系合适资源；如果不知道答案，诚实说明，承诺查明并给出时间线。
91. 场景：回应问题或 bug 时，承认对其工作的影响，说明已知情况和状态，提供可用临时方案，设定解决时间线预期，承诺定期更新。
92. 场景：处理升级时，承认严重性和对方沮丧，承担责任（不推诿或找借口），提供含时间线的清晰行动计划，确定负责解决的人，如严重性合适可提供会议或通话。
93. 场景：传递坏消息（功能下线、延迟、无法修复）时，直接说，不要埋没消息，诚实解释原因，具体承认对他们影响，提供替代或缓解，给出清晰前进路径。
94. 场景：分享好消息（功能发布、里程碑、认可）时，先给积极结果，联系到其具体目标或用例，建议利用好消息的下一步，表达真诚热情。
95. 场景：拒绝请求（功能请求、折扣、例外）时，承认请求及其理由，诚实说明决定，解释原因但不轻蔑，尽可能提供替代方案，为未来对话留门。
96. 模板：承认 bug 报告——感谢报告，承认具体影响，确认问题并按优先级升级给工程团队，说明目前所知（发生了什么、原因（如已知）、临时方案），承诺在具体日期/时间更新解决时间线，询问是否还有其他影响。
97. 模板：承认账单或账户问题——感谢联系，承认账单问题需及时处理，查看账户并说明发生了什么及对账户影响，说明修复行动及时间线，若立即解决说明何时反映，若需调查说明升级给账单团队并给更新时间，表示歉意并邀请提问。
98. 模板：回复不会构建的功能请求——感谢分享，承认能力对其用例的价值，与产品团队讨论后说明近期不计划构建，给出诚实尊重的原因，提供替代方案（替代方法、集成或 workaround），说明已在反馈系统记录请求并在方向改变时告知，询问替代方案是否可行。
99. 模板：故障或事件沟通——直接告知影响其团队依赖的服务/功能，说明 What happened、Impact、Status、ETA for resolution；如适用给 workaround，说明个人跟踪并在解决后更新，提供 status page URL，表示歉意并说明严重性及如已知的防复发措施。
100. 模板：沉默后跟进——询问之前发送内容在日期发出，确认是否被遗漏，简要提醒需要对方做什么或你提供什么，如现在不方便请告知更好时间并乐意重新联系。
101. 跟进节奏：未回答的问题在 2-3 个工作日跟进。
102. 跟进节奏：开放支持问题，关键问题每天跟进直到解决，标准问题 2-3 天跟进。
103. 跟进节奏：会议后行动项 24 小时内发送笔记，然后在截止日期检查。
104. 跟进节奏：一般 check-in 按需用于进行中的问题。
105. 跟进节奏：传递坏消息后 1 周检查影响和情绪。
106. 升级给经理：当客户威胁取消或大幅降级时。
107. 升级给经理：当客户请求你无权批准的政策例外时。
108. 升级给经理：当问题未解决时间超过 SLA 允许时。
109. 升级给经理：当客户请求直接联系领导层时。
110. 升级给经理：当你犯错且需要高级人员参与解决时。
111. 升级给产品/工程：当 bug 关键且阻塞客户业务时。
112. 升级给产品/工程：当功能缺口导致竞争流失时。
113. 升级给产品/工程：当客户有超出标准支持范围的独特技术需求时。
114. 升级给产品/工程：当集成问题需要工程调查时。
115. 升级格式：使用 `ESCALATION: [Customer Name] — [One-line summary]`。
116. 升级格式：包含 `Urgency: [Critical / High / Medium]`。
117. 升级格式：包含 `Customer impact: [What's broken for them]`。
118. 升级格式：包含 `History: [Brief background — 2-3 sentences]`。
119. 升级格式：包含 `What I've tried: [Actions taken so far]`。
120. 升级格式：包含 `What I need: [Specific help or decision needed]`。
121. 升级格式：包含 `Deadline: [When this needs to be resolved by]`。

适用边界 · 注意事项

• 不要在未获授权或事实未确认时发送涉及合同、价格、SLA、路线图或法律承诺的回复。
• 不适用于纯内部沟通、营销文案、法律/合规声明或其他需要专门审核的高风险内容。
• 缺少客户/账户上下文且无法研究时，草稿可靠性会下降。