返回技能列表

email-customer

rockscy
更新于 2 days ago
6 次查看
2
1
2
在 GitHub 上查看
文档ai

关于

This skill drafts professional, firm-yet-polite email replies for sensitive customer situations like refund requests or complaints. It is triggered when a developer pastes a customer email and asks for a response, specifically for awkward communications involving disputes or scope creep. The output is designed to be concise and effective, avoiding overly corporate language or engagement with legally threatening messages.

快速安装

Claude Code

推荐
主要方式
npx skills add rockscy/solo-skills -a claude-code
插件命令备选方式
/plugin add https://github.com/rockscy/solo-skills
Git 克隆备选方式
git clone https://github.com/rockscy/solo-skills.git ~/.claude/skills/email-customer

在 Claude Code 中复制并粘贴此命令以安装该技能

技能文档

Email Customer / 客户邮件回复

When to use

  • The dev is replying to a real customer (paying or potential).
  • The reply needs to be polite, firm, and short — not corporate, not groveling.
  • The situation is awkward: refund, dispute, scope creep, deadline push, complaint.

When NOT to use

  • A routine inquiry ("what's the price?") — answer directly, no skill needed.
  • An abusive or harassing message — those need a moderation policy, not a charming reply. Suggest: don't engage; if needed, refund and ban.
  • A legal threat — stop. Don't reply via skill. Suggest the user consult a lawyer first.

Principles

A good solo-founder reply has four properties:

  1. Acknowledge the specific concern (not "I understand your frustration").
  2. State the decision plainly in one sentence, near the top.
  3. Give one reason, no more. (Listing reasons reads as defensive.)
  4. Offer a concrete next step — a workaround, a partial refund, a deadline, a closing line.

Avoid:

  • "I'm sorry you feel that way" — not an apology, reads as dismissive.
  • "Per our policy" — bureaucratic, hides the human behind procedure.
  • Hedging multiple times in one email ("we might be able to possibly consider…").
  • More than ~120 words. If it needs more, it's a phone call or a doc.

Output format

Always produce:

  1. Subject: (one short line, no "Re: Re:")
  2. Body: (≤120 words, plain text, no signature)
  3. Internal note: (one line for the dev — what they should do operationally after sending, e.g. "issue partial refund of $19", "add to email block list")

Worked examples

Example 1: Refund request after 60 days, policy is 30

Customer:

"I bought the annual plan 60 days ago and barely used it. Can I get a refund?"

Output:

Subject: Refund on your annual plan

Body:

Hi <name>,

Refunds on annual plans are limited to the first 30 days, so a full refund isn't something I can offer here.

What I can do: switch you to month-to-month and refund the unused months as account credit, or process a 50% refund on the remaining time. Either is fine — let me know which you'd prefer.

<you>

Internal note: If they pick option 2, refund $X via Stripe. If option 1, downgrade plan in admin and credit their balance.


Example 2: Scope creep on a fixed-price contract

Customer:

"Now that the dashboard is built, can you also add a CSV export and email reports? Should be quick."

Output:

Subject: Scope on the dashboard work

Body:

Hi <name>,

CSV export and scheduled email reports are both straightforward, but they're outside the original scope. Two paths:

  1. Add them as a small follow-up at $X (≈Y days of work).
  2. Hand off the codebase as-is and your team adds them later — happy to do a 30-min walkthrough either way.

Let me know which fits better.

<you>

Internal note: If they pick option 1, send a 1-page change order before starting.


Anti-patterns

  • Don't apologize for things that aren't your fault. "Sorry the API was down" is fine; "Sorry you don't like our pricing" is not.
  • Don't promise a fix without a timeline. Either commit ("by Friday") or say "I don't have an ETA yet."
  • Don't BCC yourself for "records." Use a CRM or a notes file. BCC reads weird if the customer ever sees it.

中文版

何时使用

  • 在回复真实客户(付费的或潜在的)。
  • 回复需要礼貌、坚定、简短——不官腔,也不卑躬屈膝。
  • 场景棘手:退款、争执、范围蔓延、延期、投诉。

何时不使用

  • 日常咨询("多少钱?")——直接回答,不需要这个技能。
  • 辱骂或骚扰邮件——需要的是封禁政策,不是回复技巧。建议:不回应;必要时退款 + 拉黑。
  • 法律威胁——停。先咨询律师,再考虑回复。

原则

好的回复有四个特征:

  1. 承认具体的问题(不是泛泛的"我理解您的沮丧")。
  2. 靠前一句说清决定。
  3. 给一个理由,不要列三个(列多反而显得心虚)。
  4. 给一个具体的下一步——补偿方案、截止时间、收尾语。

避免:

  • "对您的感受感到抱歉"——不是道歉,听起来像甩锅。
  • "依据我们的政策"——官腔,把人藏在流程后面。
  • 一封邮件里反复犹豫("我们或许可以考虑…")。
  • 超过 ~120 字。再多就该改电话或长文档。

输出

  1. 主题:(一行短句)
  2. 正文:(≤120 字,纯文本,不加签名)
  3. 内部备注:(给开发者的操作指引——发完邮件还要做什么,比如"在 Stripe 退 $19"、"加入邮件黑名单")

反模式

  • 不要为不是自己的过错道歉。
  • 不要给不带时间的承诺。 要么"周五前",要么"暂时没 ETA"。
  • 不要 BCC 自己留底。 用 CRM 或笔记,BCC 万一被客户看到很尴尬。

GitHub 仓库

rockscy/solo-skills
路径: skills/email-customer
0
ai-agentsawesome-listbilingualclaude-codeclaude-skillsdeveloper-tools

相关推荐技能

railway-docs

文档

Railway Docs Skill可实时获取最新的Railway官方文档,确保回答的准确性。当开发者询问Railway功能特性、工作原理或分享docs.railway.com链接时,应优先使用此技能。它通过专门的LLM优化文档源提供最新信息,避免依赖过时记忆来回答技术问题。

查看技能

n8n-code-python

文档

该Skill为在n8n平台的Python代码节点中编写代码提供专家指导,特别适用于需要使用_input/_json/_node语法、Python标准库或了解n8n中Python限制的场景。它强调JavaScript应作为首选方案,仅当需要特定Python功能或对Python语法更熟悉时才使用Python。Skill提供了快速入门模板和关键注意事项,帮助开发者在n8n中高效编写Python代码。

查看技能

archon

文档

Archon Skill为开发者提供了基于RAG的语义搜索和项目任务管理功能,可通过REST API访问知识库。它支持文档搜索、网站爬取、文件上传和版本控制,适用于技术文档查询和项目管理场景。首次使用时需要配置Archon主机地址,建议在处理外部文档时优先使用该Skill。

查看技能

n8n-code-javascript

文档

这个Skill为n8n工作流中的JavaScript代码节点提供专业指导,涵盖数据处理、HTTP请求和日期操作等核心场景。它详细解释了如何正确使用n8n特有的`$input`/`$json`语法、`$helpers`工具以及DateTime对象,并包含关键的错误排查和模式选择建议。开发者通过该Skill能快速掌握Code节点的正确返回格式、数据访问方法和常见陷阱解决方案。

查看技能