Customer Support 插件 /draft-response 技能实战面向情境与客户关系的专业回复起草指南【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins本文基于knowledge-work-plugins开源仓库中 draft-response 技能文档 编写并结合 customer-support 插件 README、CONNECTORS.md 及同目录其他技能文件进行源码级佐证与扩充。/draft-response是 customer-support 插件中负责起草对外客户回复的核心技能它把一次客户沟通从凭感觉写升级为结构化产出——先解析情境、再检索上下文、生成定制草稿、执行质量检查、最后提供多轮迭代选项。读完本文你将掌握如何用一句话触发技能、理解其五步工作流每一步的设计意图、熟练套用五种常用场景模板并能结合渠道、客户关系阶段与语气光谱写出既不越权承诺、又让客户感到被认真对待的专业回复。技能定位从情境到成稿的回复生成器在 customer-support/README.md 的命令表中/draft-response被定义为 Draft a customer-facing response for any situation即面向任意情境的客户回复起草命令。技能文档的 frontmatter 给出了更精确的触发条件draft-response/SKILL.mdname: draft-response description: Draft a professional customer-facing response tailored to the situation and relationship. Use when answering a product question, responding to an escalation or outage, delivering bad news like a delay or wont-fix, declining a feature request, or replying to a billing issue. argument-hint: situation description从 description 可以看出本技能的适用面覆盖了客服工作几乎全部的高频场景产品问题解答、升级/故障响应、坏消息传达延期、wont-fix、婉拒功能请求、账单问题回复。它与其他四个技能构成完整的客服工作闭环见 README 命令表命令职责与 draft-response 的协作/ticket-triage分类、定级P1-P4、路由产出建议首条回复与自动响应模板/customer-research多源检索、置信度评分为回复提供事实与证据/draft-response起草情境化回复本文主角/customer-escalation打包升级简报触发升级后仍需对客户保持沟通/kb-article沉淀知识库文章把反复出现的回复固化为自助内容基本用法技能采用斜杠命令语法通过argument-hint明确提示需要传入情境描述/draft-response context about the customer question, issue, or request文档给出了四类典型调用示例SKILL.md/draft-response Acme Corp is asking when the new dashboard feature will ship—— 产品上线时间问询/draft-response Customer escalation — their integration has been down for 2 days—— 升级事件/draft-response Responding to a feature request we wont be building—— 婉拒功能请求/draft-response Customer hit a billing error and wants a resolution ASAP—— 账单错误客户要求快速解决调用时提供的情境越具体后续工作流中的理解情境环节就能解析出越准确的参数。README 中的示例工作流展示了期望的输出形态README.md输入客户升级——集成已宕机 2 天且情绪沮丧Claude 应生成富有同理心、专业的回复承认沮丧、承担责任、给出带时间线的行动计划并提供通话选项。五步工作流从情境解析到可迭代草稿技能的正文主体是一条五步流水线每一环节都有明确的产出物。第 1 步理解情境Understand the Context解析用户输入回答六个维度的上下文问题SKILL.mdCustomer客户这份沟通是写给谁的如有可能查找账户上下文Situation type情境类型问题、故障、升级、公告、谈判、坏消息、好消息、跟进Urgency紧急程度是否时间敏感客户已经等了多久Channel渠道邮件、支持工单、聊天或其他据此调整正式程度Relationship stage关系阶段新客户、老客户、沮丧/已升级客户Stakeholder level干系人层级终端用户、经理、高管、技术人员、业务人员这六个维度直接决定后续的语气、篇幅与承诺边界是整个工作流的信息基座。第 2 步检索上下文Research Context从可用数据源收集背景信息SKILL.md。注意文档中出现的~~email、~~chat、~~CRM、~~support platform、~~knowledge base这些带双波浪线前缀的占位符——根据 CONNECTORS.md插件是**工具无关tool-agnostic**的~~category表示用户在该类别下接入的任意工具例如~~support platform可能是 Intercom、Zendesk 或任何提供 MCP server 的支持工具。当前 customer-support 插件预配置的连接包括类别占位符内置服务器其他可选聊天~~chatSlackMicrosoft Teams邮件~~emailMicrosoft 365—支持平台~~support platformIntercomZendesk、Freshdesk、HubSpot Service HubCRM~~CRMHubSpotSalesforce、Pipedrive知识库~~knowledge baseGuru、NotionConfluence、Help Scout项目跟踪~~project trackerAtlassian (Jira/Confluence)Linear、Asana完整表格见 CONNECTORS.md。各数据源在回复起草中的用途~~email与该客户在此话题上的历史往来、此前分享过的承诺与时间线、现有邮件串的语气风格~~chat关于该客户或话题的内部讨论、产品/工程/领导层的指导意见、相似情境的历史处理方式~~CRM如已连接账户详情与套餐层级、联系人与关键干系人、历史升级或敏感问题~~support platform如已连接关联工单及其解决方案、已知问题或临时规避方案、SLA 状态与响应时间承诺~~knowledge base可引用的官方文档或帮助文章、产品路线图信息若可对外分享、政策或流程文档README 的配置说明指出未连接任何数据源时插件会要求手动提供上下文并给出可自行填充的框架与模板README.md。这意味着本工作流在有连接和无连接两种环境下都能运转只是检索深度不同。第 3 步生成草稿Generate the Draft技能定义了标准化的草稿输出结构SKILL.md## 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]这个模板的精妙之处在于客户可见部分与内部备忘部分强制分离Notes for You明确标注 internal — do not send要求 Agent 在正文之外同步产出一段内部说明解释为什么这样措辞、发送前需要核实哪些事实、存在什么风险、发送后要做什么跟进、是否需要他人先审阅。这与客服工作的真实场景高度吻合——回复不是孤立的文字而是一连串后续动作的起点。第 4 步质量检查Run Quality Checks草稿交付前必须逐项核验SKILL.md语气与情境和客户关系匹配没有超出授权范围的承诺没有不应对外分享的产品路线图细节对过往对话的引用准确下一步行动与负责人清晰适合干系人层级对高管不过度技术化对工程师不过度含糊篇幅适合渠道聊天更短邮件更完整这组检查项本质上是把专业客服的肌肉记忆显式化为可勾选的清单任何一条不满足都应回头修改草稿。第 5 步提供迭代选项Offer Iterations草稿呈现后技能要求主动给出迭代出口SKILL.md需要我调整语气吗更正式、更随意、更富同理心、更直接需要添加或删减某些要点吗需要更短或更长吗需要为不同的干系人各起草一版吗需要我把内部升级备忘也写出来吗需要我准备一条在 [X 天后] 若无回应时发送的跟进消息吗迭代选项体现了该技能的设计哲学第一稿是基线而非终点语气、长度、受众、后续动作都可以按需调整。客户沟通最佳实践原则、结构与篇幅七大核心原则文档给出七条普适原则SKILL.mdLead with empathy以同理心开场先承认客户的处境再跳入解决方案Be direct直接客户很忙结论先行bottom-line-up-frontBe honest诚实绝不夸大承诺、绝不误导、绝不用术语掩盖坏消息Be specific具体用具体细节、时间线和姓名避免含糊语言Own it承担责任该担责时担责说 We 而非 the system 或 the processClose the loop闭环每条回复都要有清晰的下一步或行动号召Match their energy匹配情绪客户沮丧就先共情客户兴奋就热情回应回复结构四段式对大多数客户沟通遵循固定结构SKILL.md1. Acknowledgment / Context1-2 句 - 承认对方所说、所问或所经历的 - 表明你理解他们的处境 2. Core Message1-3 段 - 传递主要信息、答案或进展 - 具体、实在包含他们需要的相关细节 3. Next Steps1-3 个要点 - 你方将做什么、何时做 - 对方需要做什么如有 - 下次何时再联系 4. Closing1 句 - 温暖而专业的落款 - 强调如有需要你随时可用这一结构同时体现在五种场景模板中——每份模板几乎都能拆解为共情承认 → 事实与状态 → 下一步/时间线 → 落款四个部分。篇幅指南按渠道控制篇幅SKILL.md聊天/IM1-4 句立即切入要点支持工单回复1-3 个短段落结构化、可扫读邮件最多 3-5 段尊重对方收件箱升级响应需要多详尽就多详尽但要用标题组织清晰高管沟通越短越好2-3 段以内数据驱动语气与风格指南语气光谱、关系阶段与写作规则语气光谱Tone Spectrum不同情境对应不同语气特征SKILL.md情境语气特征好消息 / 胜利Celebratory热情、温暖、祝贺、前瞻例行更新Professional清晰、简洁、信息充分、友好技术回复Precise准确、详细、结构化、耐心交付延期Accountable诚实、道歉、行动导向、具体坏消息Candid直接、共情、解决方案导向、尊重故障 / 宕机Urgent立即、透明、可行动、安抚升级Executive沉着、承担责任、呈现计划、自信账单 / 账户Precise清晰、基于事实、共情、聚焦解决按关系阶段调整语气同一条消息对三种关系阶段的客户写法不同SKILL.md新客户0-3 个月更正式专业提供额外上下文和解释不假设对方已了解主动提供帮助与资源通过可靠性和响应速度建立信任。老客户3 个月以上温暖、协作可以引用共同历史与过往对话沟通更直接高效表现出对他们目标与优先事项的了解。沮丧或已升级客户额外的共情与承认响应速度要体现紧迫感给出带具体承诺的行动计划缩短反馈回路。写作风格规则应当DO使用主动语态Well investigate 而非 This will be investigated个人承诺用 I团队承诺用 we指派行动时点名具体的人Sarah from our engineering team will...使用客户的术语而非你的内部黑话给出具体日期时间而非相对说法by Friday January 24 而非 in a few days长回复用标题或要点拆分禁止DONT使用企业套话或流行词synergy、leverage、paradigm shift把责任推给其他团队、系统或流程用被动语态逃避责任Mistakes were made加入削弱信心的多余保留或含糊其辞无谓抄送——只保留真正需要参与对话的人过度使用感叹号每封邮件最多一个甚至可以不用情境化策略六类高频场景的应对要点在模板之上技能为六类具体情境给出了策略要点SKILL.md解答产品问题以直接答案开头提供相关文档链接如需可帮其对接正确资源若不知道答案诚实说明、承诺查清并给出时间线。响应故障或 bug承认对其工作的影响说明你对问题的已知信息与状态如有可能提供临时规避方案设定解决时间线预期承诺按固定间隔更新。处理升级承认严重性与对方的沮丧承担责任不推诿、不找借口给出带时间线的清晰行动计划明确负责解决的人员视严重程度提议会议或电话。传达坏消息功能下线、延期、无法修复直接——不要埋没消息诚实解释原因承认对他们产生的具体影响提供替代方案或缓解措施给出清晰的前进路径。分享好消息功能发布、里程碑、认可以积极结果开头联系到对方的具体目标或用例建议利用好消息的下一步表达真诚的热情。婉拒请求功能请求、折扣、例外承认请求及其理由对决定诚实解释原因但不轻慢尽可能提供替代方案为未来对话留门。五种常用场景模板文档提供了五份可直接套用的完整模板覆盖客服最高频的沟通场景。以下完整呈现并给出关键字段说明。模板一确认 Bug 报告Hi [Name], Thank you for reporting this — I can see how [specific impact] would be frustrating for your team. Ive confirmed the issue and escalated it to our engineering team as a [priority level]. Heres what we know so far: - [Whats happening] - [Whats causing it, if known] - [Workaround, if available] Ill 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]要点解析首段用我能看到 [具体影响] 会让你的团队沮丧完成共情承认第二段同步已知事实发生了什么/原因/规避方案其中[priority level]可直接对齐 ticket-triage 的 P1-P4 定级框架随后给出明确更新时间点绝对日期时间而非很快最后开放式收尾邀请对方补充影响范围。模板二确认账单或账户问题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. Ive looked into your account and heres what Im seeing: - [What happened — clear factual explanation] - [Impact on their account — charges, access, etc.] Heres what Im 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: Im escalating this to our billing team and will have an update for you by [specific date].] Im sorry for the inconvenience. Let me know if you have any questions about your account. Best, [Your name]要点解析模板内置了立即解决与需要调查两条分支文案对应账单问题的两种真实结局事实陈述要求清晰、基于事实呼应语气光谱中 Billing 的 Precise 特征且明确标注影响范围费用、访问权限等。模板三回应不会构建的功能请求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 isnt something were 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] Ive also documented your request in our feedback system, and if our direction changes, Ill let you know. Would any of these alternatives work for your team? Happy to dig deeper into any of them. Best, [Your name]要点解析这是婉拒的最佳实践范本——先承认请求价值再诚实说明决策与原因举例给出了用例太窄、与架构方向冲突等合理解释范式随即转向替代方案最后说明已录入反馈系统并留下沟通口子符合情境策略中leave the door open的要求。模板四宕机或事故沟通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 well update every X hours] [If applicable: In the meantime, you can [workaround].] Im 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. Im sorry for the disruption to your teams work. We take this seriously and [what youre doing to prevent recurrence if known]. [Your name]要点解析事故沟通强调主动触达I wanted to reach out directly与透明结构——用加粗字段快速呈现发生了什么/影响/状态/预计恢复时间四要素状态字段的五种取值investigating / identified / fixing / resolved可与 customer-escalation 的严重度分级联动Im personally tracking this 用第一人称建立个人责任感结尾道歉并说明防复发措施。模板五静默后跟进Hi [Name], I wanted to check in — I sent over [what you sent] on [date] and wanted to make sure it didnt get lost in the shuffle. [Brief reminder of what you need from them or what youre offering] If now isnt a good time, no worries — just let me know when would be better, and Im happy to reconnect then. Best, [Your name]要点解析跟进消息的要点是不给压力——just let me know when would be better 把主动权交还给客户同时用 [date] 精确标注此前沟通时间避免模糊表述。跟进与升级指导节奏、触发条件与升级格式跟进节奏Follow-up Cadence情境跟进时机未回复的问题2-3 个工作日未关闭的支持工单关键问题每日跟进直至解决标准问题 2-3 天会后行动项24 小时内发送纪要然后在截止日核查常规问候按需用于持续中的问题传达坏消息之后1 周后核查影响与情绪表格见 SKILL.md。注意这条跟进节奏与 customer-escalation 中的严重度跟进表Critical 每 2 小时 / High 每 4 小时 / Medium 每日互补前者管常规沟通后者管升级后的高强度追踪。何时升级When to Escalate升级给直属经理当客户威胁取消或大幅降级客户要求你无权批准的例外问题超过 SLA 时限仍未解决客户要求直接联系领导层你犯了需要高层参与解决的错误升级给产品/工程当Bug 严重且阻塞客户业务功能缺口正造成竞争性流失客户有超出标准支持范围的独特技术要求集成问题需要工程调查升级格式Escalation FormatESCALATION: [Customer Name] — [One-line summary] Urgency: [Critical / High / Medium] Customer impact: [Whats broken for them] History: [Brief background — 2-3 sentences] What Ive tried: [Actions taken so far] What I need: [Specific help or decision needed] Deadline: [When this needs to be resolved by]格式见 SKILL.md。这份精简版升级备忘适合附在回复草稿的 Escalation note 内部备忘之后也可与 /customer-escalation 生成的完整升级简报配套使用。实战串联把技能嵌入完整客服闭环/draft-response不是孤立命令它与同插件的其他技能构成一条完整的处理流水线。以一个典型场景为例新工单进来先用/ticket-triage完成分类定级P1-P4与路由其自动响应模板可作为首条回复起点ticket-triage/SKILL.md若需要事实支撑用/customer-research跨数据源检索并给出置信度评分customer-research/SKILL.md用/draft-response基于检索结果生成情境化正式回复若需工程/产品介入用/customer-escalation打包完整升级简报customer-escalation/SKILL.md问题解决后用/kb-article把方案沉淀为自助文章降低同类工单复发kb-article/SKILL.md。在无任何数据源连接的环境下技能依然可用——正如 README 所述插件会要求手动提供上下文并提供可填充的框架与模板README.md。有连接时~~占位符会被实际接入的工具Intercom、HubSpot、Slack、Guru 等自动替换检索环节才能真正读取工单历史、账户信息与内部讨论。无论哪种模式/draft-response的最终产出都遵循同一套标准情境解析 → 上下文检索 → 结构化草稿 → 质量检查 → 迭代出口。小结/draft-response把写一封得体的客户回复这一看似主观的任务拆解为可重复、可检查、可迭代的工程流程。其核心价值在于三点一是情境驱动——语气、篇幅、承诺边界全部由客户关系阶段与渠道决定二是证据支撑——通过~~占位符接入邮件、聊天、CRM、工单与知识库避免回复建立在猜测之上三是闭环思维——草稿附带的内部备忘、质量检查清单与跟进节奏确保回复不是终点而是客户旅程中的一个节点。结合本仓库同目录的其他四个技能可以覆盖从工单分流到知识沉淀的完整客服生命周期。【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考