draft-response

/draft-response

如果您看到不熟悉的占位符，或需要检查已连接哪些工具，请参阅 CONNECTORS.md。

起草一份专业的面向客户回复，根据具体情况、客户关系和沟通语境进行定制。

用法

/draft-response <context about the customer question, issue, or request>

示例：

• /draft-response Acme Corp 询问新仪表盘功能何时上线
• /draft-response 客户升级投诉——其集成已中断 2 天
• /draft-response 回复一项我们不会开发的功能请求
• /draft-response 客户遇到账单错误，希望尽快解决

工作流程

1. 理解语境

解析用户输入，以确定：

• 客户：沟通对象是谁？如有可用的账户信息，请查询账户背景。
• 情况类型：提问、问题、升级、公告、协商、坏消息、好消息、跟进
• 紧急程度：是否具有时效性？客户已等待多久？
• 渠道：邮件、支持工单、聊天或其他（相应调整正式程度）
• 关系阶段：新客户、长期客户、不满/已升级
• 利益相关者级别：终端用户、经理、高管、技术人员、业务人员

2. 调研背景

从可用来源收集相关背景信息：

~~邮件：

• 与该客户就此话题的往来邮件
• 此前已作出的任何承诺或时间安排
• 现有邮件往来的语气和风格

~~聊天：

• 关于该客户或话题的内部讨论
• 来自产品、工程或管理层的任何指导
• 类似情况及其处理方式

~~CRM（如已连接）：

• 账户详情与套餐级别
• 联系信息与关键利益相关者
• 此前的升级或敏感问题

~~支持平台（如已连接）：

• 相关工单及其解决方案
• 已知问题或变通方法
• SLA 状态与响应时间承诺

~~知识库：

• 可供引用的官方文档或帮助文章
• 产品路线图信息（如可对外分享）
• 政策或流程文档

3. 生成草稿

生成针对具体情况定制的回复：

## Draft Response

**To:** [Customer contact name]
**Re:** [Subject/topic]
**Channel:** [Email / Ticket / Chat]
**Tone:** [Empathetic / Professional / Technical / Celebratory / Candid]

---

[Draft response text]

---

### Notes for You (internal — do not send)
- **Why this approach:** [Rationale for tone and content choices]
- **Things to verify:** [Any facts or commitments to confirm before sending]
- **Risk factors:** [Anything sensitive about this response]
- **Follow-up needed:** [Actions to take after sending]
- **Escalation note:** [If this should be reviewed by someone else first]

4. 进行质量检查

在呈现草稿之前，请核实：

• 语气与情况及客户关系相匹配
• 没有超出授权范围的承诺
• 不包含不应对外分享的产品路线图细节
• 对此前对话的引用准确无误
• 下一步与责任人清晰明确
• 适合利益相关者级别（对高管不过于技术化，对工程师不过于笼统）
• 长度适合渠道（聊天更简短，邮件可更完整）

5. 提供迭代选项

呈现草稿后：

• "需要我调整语气吗？（更正式、更随意、更富同理心、更直接）"
• "需要增加或删除某些具体要点吗？"
• "需要我把内容写得更短或更长吗？"
• "需要为其他利益相关者起草一个版本吗？"
• "需要我同时起草内部升级说明吗？"
• "需要我准备一条在 [X 天] 后仍无回复时发送的跟进消息吗？"

---

客户沟通最佳实践

核心原则

1. 以同理心开场：在提出解决方案之前，先认可客户的处境
2. 直截了当：切入重点——客户很忙。结论先行。
3. 坦诚相待：绝不过度承诺、不误导，也不用术语掩盖坏消息
4. 具体明确：使用具体细节、时间节点和姓名，避免含糊措辞
5. 主动担责：在适当时承担责任。用"我们"，而不是"系统"或"流程"
6. 闭环管理：每份回复都应有明确的下一步或行动号召
7. 匹配对方情绪：如果客户感到沮丧，先表达同理心。如果客户很兴奋，则予以热情回应。

回复结构

对于大多数客户沟通，请遵循以下结构：

1. Acknowledgment / Context (1-2 sentences)
   - Acknowledge what they said, asked, or are experiencing
   - Show you understand their situation

2. Core Message (1-3 paragraphs)
   - Deliver the main information, answer, or update
   - Be specific and concrete
   - Include relevant details they need

3. Next Steps (1-3 bullets)
   - What YOU will do and by when
   - What THEY need to do (if anything)
   - When they'll hear from you next

4. Closing (1 sentence)
   - Warm but professional sign-off
   - Reinforce you're available if needed

篇幅指南

• 即时聊天/IM：1-4 句。直接切入重点。
• 支持工单回复：1-3 个简短段落。结构清晰，便于快速浏览。
• 邮件：最多 3-5 个段落。尊重对方的收件箱。
• 升级回复：根据需要尽量详尽，但要用标题做好结构化组织。
• 高管沟通：越简短越好。最多 2-3 个段落。以数据为支撑。

语气与风格指南

语气谱系

场景	语气	特点
好消息 / 成果	庆祝	热情、温暖、表示祝贺、着眼未来
例行更新	专业	清晰、简洁、信息充分、友好
技术回复	精确	准确、详细、结构化、耐心
交付延迟	担责	诚实、致歉、以行动为导向、具体
坏消息	坦率	直接、共情、以解决方案为导向、尊重对方
问题 / 故障	紧急	及时、透明、可执行、让人安心
升级	高管式	沉稳、主动担责、给出计划、自信
账单 / 账户	精确	清晰、客观、共情、以解决问题为导向

根据客户关系阶段调整语气

新客户（0-3 个月）：

• 更正式、更专业
• 提供额外的背景与解释（不要假设对方已了解）
• 主动提供帮助与资源
• 通过可靠性和及时响应建立信任

老客户（3 个月以上）：

• 温暖且协作
• 可以提及共同的历史和过往沟通
• 沟通更直接、更高效
• 体现出对客户目标和优先事项的了解

情绪受挫或已升级的客户：

• 给予额外的共情与确认
• 响应时间要有紧迫感
• 提供具体承诺的可执行行动计划
• 缩短反馈周期

写作风格规则

应当：

• 使用主动语态（“我们将进行调查”，而非“此事将被调查”）
• 个人承诺使用“我”，团队承诺使用“我们”
• 分配行动任务时点名具体的人（“我们工程团队的 Sarah 将……”）
• 使用客户的术语，而非内部行话
• 写明具体的日期和时间，而非相对表述（写“1 月 24 日周五前”，而非“过几天”）
• 用标题或项目符号拆分较长的回复

不应当：

• 使用企业套话或流行词（如“协同效应”“赋能”“范式转变”）
• 将责任推给其他团队、系统或流程
• 使用被动语态来回避责任（如“出现了错误”）
• 加入不必要的保留或模糊表述，以致削弱信心
• 不必要地抄送他人——仅包括需要参与对话的人
• 过度使用感叹号（邮件中最多一个，也可以不用）

针对不同情境的处理方式

回答产品问题：

• 先给出直接答案
• 提供相关文档链接
• 如有需要，主动提出为其对接合适的资源
• 如果不知道答案：坦诚说明，承诺去查明，并给出时间安排

回应问题或缺陷：

• 认可该问题对其工作造成的影响
• 说明已掌握的问题情况及当前状态
• 如有可用的变通方案，请一并提供
• 明确解决时间预期
• 承诺定期更新进展

处理升级事件：

• 认可问题的严重性以及对方的不满情绪
• 主动承担责任（不推诿、不找借口）
• 提供明确的行动计划和时间表
• 指定负责推动解决的责任人
• 如果问题的严重程度适合，主动提议召开会议或电话沟通

传达坏消息（功能下线、延期、无法修复）：

• 直言相告，不要掩盖或淡化消息
• 如实说明原因
• 具体说明该消息对其造成的影响
• 提供替代方案或缓解措施
• 给出清晰的后续路径

分享好消息（功能上线、里程碑、获得认可）：

• 先说明积极的结果
• 将其与对方的具体目标或使用场景相联系
• 建议后续步骤，以充分利用这一好消息
• 表达真诚的热情

拒绝请求（功能需求、折扣、例外处理）：

• 认可该请求及其背后的理由
• 坦诚说明决定
• 解释原因，但避免显得轻视
• 在可能的情况下提供替代方案
• 为未来的沟通留有余地

常见场景的回复模板

确认收到缺陷报告

Hi [Name],

Thank you for reporting this — I can see how [specific impact] would be
frustrating for your team.

I've confirmed the issue and escalated it to our engineering team as a
[priority level]. Here's what we know so far:
- [What's happening]
- [What's causing it, if known]
- [Workaround, if available]

I'll update you by [specific date/time] with a resolution timeline.
In the meantime, [workaround details if applicable].

Let me know if you have any questions or if this is impacting you in
other ways I should know about.

Best,
[Your name]

确认收到账单或账户问题

Hi [Name],

Thank you for reaching out about this — I understand billing issues
need prompt attention, and I want to make sure this gets resolved
quickly.

I've looked into your account and here's what I'm seeing:
- [What happened — clear factual explanation]
- [Impact on their account — charges, access, etc.]

Here's what I'm doing to fix this:
- [Action 1 — with timeline]
- [Action 2 — if applicable]

[If resolution is immediate: "This has been corrected and you should
see the change reflected within [timeframe]."]
[If needs investigation: "I'm escalating this to our billing team
and will have an update for you by [specific date]."]

I'm sorry for the inconvenience. Let me know if you have any
questions about your account.

Best,
[Your name]

回复不会开发的功能需求

Hi [Name],

Thank you for sharing this request — I can see why [capability] would
be valuable for [their use case].

I discussed this with our product team, and this isn't something we're
planning to build in the near term. The primary reason is [honest,
respectful explanation — e.g., it serves a narrow use case, it conflicts
with our architecture direction, etc.].

That said, I want to make sure you can accomplish your goal. Here are
some alternatives:
- [Alternative approach 1]
- [Alternative approach 2]
- [Integration or workaround if applicable]

I've also documented your request in our feedback system, and if our
direction changes, I'll let you know.

Would any of these alternatives work for your team? Happy to dig
deeper into any of them.

Best,
[Your name]

故障或事件通告

Hi [Name],

I wanted to reach out directly to let you know about an issue affecting
[service/feature] that I know your team relies on.

**What happened:** [Clear, non-technical explanation]
**Impact:** [How it affects them specifically]
**Status:** [Current status — investigating / identified / fixing / resolved]
**ETA for resolution:** [Specific time if known, or "we'll update every X hours"]

[If applicable: "In the meantime, you can [workaround]."]

I'm personally tracking this and will update you as soon as we have a
resolution. You can also check [status page URL] for real-time updates.

I'm sorry for the disruption to your team's work. We take this seriously
and [what you're doing to prevent recurrence if known].

[Your name]

长时间未回复后的跟进

Hi [Name],

I wanted to check in — I sent over [what you sent] on [date] and
wanted to make sure it didn't get lost in the shuffle.

[Brief reminder of what you need from them or what you're offering]

If now isn't a good time, no worries — just let me know when would be
better, and I'm happy to reconnect then.

Best,
[Your name]

跟进与升级指南

跟进频率

情况	跟进时间
未回复的问题	2-3 个工作日
未关闭的支持问题	关键问题每日跟进直至解决，普通问题每 2-3 天跟进
会后待办事项	24 小时内发送会议纪要，然后在截止日期前跟进
一般性回访	针对持续存在的问题按需跟进
传达坏消息之后	1 周后确认影响及客户情绪

何时升级

以下情况需升级至经理：

• 客户威胁取消服务或大幅降级订阅
• 客户要求例外处理，而你无权批准
• 问题的未解决时长超出 SLA 允许范围
• 客户要求直接联系管理层
• 你犯了错误，需要高级别人员介入解决

以下情况需升级至产品/工程团队：

• 缺陷严重且阻碍客户业务开展
• 功能缺口导致竞争性流失
• 客户有超出标准支持范围的特殊技术需求
• 集成问题需要工程团队排查

升级格式：

ESCALATION: [Customer Name] — [One-line summary]

Urgency: [Critical / High / Medium]
Customer impact: [What's broken for them]
History: [Brief background — 2-3 sentences]
What I've tried: [Actions taken so far]
What I need: [Specific help or decision needed]
Deadline: [When this needs to be resolved by]