别让用户的问题石沉大海：vibe 项目的客服工单系统实战

站内有一篇《用户反馈闭环实战》，讲的是产品决策环：用户反馈怎么收集、怎么定优先级、怎么做进产品、怎么告诉用户"我们做了"。本文讲的是另一条环：支持交付环——用户遇到问题（付不了款、数据不见了、功能报错），这个问题变成一张工单，经过分诊、处理、解决、关闭，全程有时限、有记录、有回访。一个管"做什么"，一个管"修多快"；前者决定产品走多远，后者决定用户留不留。两篇互为姊妹，本文只讲后者。

没有工单系统，你的问题散落在五个地方

一人团队的客服现状通常是这样的：用户在站内表单留了言，发了封邮件到你的个人邮箱，在 Discord 里 @ 你，在 Twitter 上私信你，还在应用内点了"报错"按钮。你每天的工作变成到处找消息：早上回邮件，中午看 Discord，晚上刷 Twitter。结果是：

• 丢单：某条 Discord 消息沉了，三天后用户流失了你都不知道为什么。
• 重复劳动：同一个 bug，三个人在三个渠道各问一遍，你回了三遍。
• 没有优先级："支付失败"和"建议加个暗色模式"躺在同一个收件箱里，你凭心情决定先回哪个。
• 无法复盘：月底你想知道"这个月用户最多抱怨什么"，翻聊天记录翻到崩溃。

工单系统的本质就一句话：把散落的问题收进一个池子，给每张单编号、分级、计时。它不解决客服问题，它让你"看得见"客服问题——而看得见，是解决的第一步。

工单的生命周期：6 个状态

图 1：工单生命周期。6 个状态走完一张单；关键设计有三处：SLA 从"新建"开始计时、"待用户回复"暂停计时、"已解决"不满意可以"重开"而不是新开一张单。

状态机是工单系统的骨架，设计时抓住三个关键决策：

1. SLA 从"新建"开始计时，到"已解决"暂停：用户可感知的等待时间，就是你的 SLA 时间。不要从"分诊"开始算——用户不关心你的内部流程。
2. "待用户回复"暂停计时：你问用户要日志、用户三天没回，这三天不能算你的响应时长。状态机里单独一个状态，就是为了计时公平。
3. "重开"而不是"新开"：用户对解决方案不满意，点"重开"回到"处理中"，上下文（历史回复、附件、经办人）全保留。新开一张单等于让用户把问题再讲一遍——这是客服体验里最招人恨的设计。

数据模型（Prisma）直接照着状态机写：

model Ticket {
  id            String       @id @default(cuid())
  number        Int          @unique @default(autoincrement()) // 对外工单号 #1024，用户好记
  title         String
  status        TicketStatus @default(OPEN)
  priority      Priority     @default(P3)
  channel       String       // form | email | widget | discord | inapp
  reporterEmail String
  reporterId    String?      // 登录用户关联
  assigneeId    String?      // 经办人，一人团队就是你自己
  firstReplyAt  DateTime?    // 首次响应时间，SLA 用
  resolvedAt    DateTime?
  satisfaction  Int?         // 1-5 关闭后回访评分
  createdAt     DateTime     @default(now())
  replies       TicketReply[]

  @@index([status, priority]) // 分诊看板就靠这个索引
}

enum TicketStatus {
  OPEN        // 新建
  TRIAGED     // 分诊中
  IN_PROGRESS // 处理中
  PENDING_USER// 待用户回复
  RESOLVED    // 已解决
  REOPENED    // 重开
  CLOSED      // 已关闭
}

enum Priority { P1 P2 P3 P4 }

model TicketReply {
  id        String   @id @default(cuid())
  ticketId  String
  ticket    Ticket   @relation(fields: [ticketId], references: [id], onDelete: Cascade)
  author    String   // user | agent | system
  body      String   @db.Text
  internal  Boolean  @default(false) // 内部备注，用户不可见
  createdAt DateTime @default(now())
}

注意 internal 字段：内部备注和用户可见回复必须物理隔离。把"这个用户真难缠"发给用户本人，是客服事故里最社死的一种。一个布尔字段，挡住一整类事故。

渠道统一：所有入口汇成一个收件箱

图 2：渠道统一。原则：用户从哪来不重要，工单必须进同一个池子——否则你永远在到处找消息。

落地时按渠道逐个接，但顺序有讲究：

1. 站内表单最先：字段你说了算（问题类型、复现步骤、联系方式），信息结构化程度最高，分诊最容易。
2. 邮件转工单其次：support@你的域名.com 接进来，每封邮件自动建单。注意去重：同一用户 10 分钟内连发 3 封，大概率是"没收到回复又发了一遍"，按发件人 + 主题相似度合并，别建 3 张单。
3. 聊天 widget 再次：网站右下角的小气泡。它的价值不是"实时聊天"（一人团队做不到 7×24），而是把"想说话"的用户拦在站内，而不是流失到 Twitter 上公开吐槽。离线时 widget 显示"留言模式"，消息照样进工单池。
4. 社群/Discord 最后：社群是讨论的地方，不是客服的地方。策略是"引导"：机器人检测到求助关键词，自动回复"已为你建单 #1024，点此补充信息"，把对话迁回工单系统。

一个观点：渠道越多，统一收件箱越重要。每新增一个渠道，不接进收件箱就等于新增一个"消息黑洞"。接渠道的验收标准只有一条：从这个渠道来的问题，能不能在收件箱里被编号、分级、计时。

自动分诊：一人团队的时间杠杆

分诊是工单系统里 ROI 最高的自动化：它决定"哪张单先被看见"。一人团队不需要机器学习，关键词路由 + 规则定级足够用：

// 自动分诊：关键词路由 + 优先级判定（跑在新工单创建时）
const ROUTES: Array<{ keywords: string[]; priority: "P1" | "P2" | "P3" | "P4"; tag: string }> = [
  { keywords: ["支付失败", "扣款", "payment failed", "charge"], priority: "P1", tag: "billing" },
  { keywords: ["数据丢失", "不见了", "data lost", "500", "崩溃"], priority: "P1", tag: "critical" },
  { keywords: ["登录不上", "login", "打不开", "报错"], priority: "P2", tag: "account" },
  { keywords: ["建议", "希望加个", "feature request"], priority: "P4", tag: "feedback" },
];

export function triage(title: string, body: string) {
  const text = `${title} ${body}`.toLowerCase();
  for (const r of ROUTES) {
    if (r.keywords.some((k) => text.includes(k.toLowerCase()))) {
      return { priority: r.priority, tag: r.tag, auto: true };
    }
  }
  return { priority: "P3", tag: "general", auto: true }; // 兜底：默认 P3，人工复核
}

// P1 自动升级：15 分钟无人认领 → 发短信/打电话叫醒你
export async function escalateOverdue() {
  const overdue = await db.ticket.findMany({
    where: {
      status: "OPEN",
      priority: "P1",
      createdAt: { lt: new Date(Date.now() - 15 * 60 * 1000) },
    },
  });
  for (const t of overdue) await notifyOwner(`P1 工单 #${t.number} 15 分钟无人处理！`);
  // 跑在 cron 里，每 5 分钟一次
}

分诊之后，自动回复是第二杠杆。用户建单后 10 秒内收到"已收到，工单 #1024，预计 4 小时内回复"，焦虑值下降一半。自动回复模板三要素：工单号（可追踪）、预期时间（设预期）、自助链接（常见问题先自己看）。注意：自动回复不等于已读乱回，它承诺的是"我们看见了"，不是"我们解决了"——预期管理是客服的一半工作。

SLA：先分级，再谈服务

图 3：一人团队的现实 SLA。先定 SLA 再写代码：没有分级的工单系统，等于所有工单都是 P1——也就是都没有优先级。

SLA（服务等级协议）听起来像大公司的东西，但一人团队更需要——因为你的时间是最稀缺的资源。图 3 的四档是给独立开发者的现实版本：

• P1 致命（支付挂了、数据丢了）：15 分钟内响应，4 小时内解决。这是唯一需要"叫醒你"的级别。
• P2 严重（核心功能不可用）：1 小时内响应，24 小时内解决。
• P3 一般（体验问题、小 bug）：4 小时内响应，72 小时内解决。
• P4 建议（功能建议、咨询）：24 小时内响应，7 天内解决——这类单大部分会流向反馈闭环的需求池。

三个实战忠告：

1. SLA 写进自动回复里："P3 问题预计 72 小时内解决"——用户知道了预期，就不会每 2 小时催一次。预期管理 again。
2. SLA 到期前预警，不要到期后复盘：cron 每 15 分钟扫一次"距 SLA 到期不足 1 小时且未解决"的单，推给你。复盘是改进用的，预警是救命用的。
3. P1 的数量是健康指标：一周超过 3 个 P1，说明不是客服问题，是产品质量问题——停下新功能，先修 P1 的根因。

处理 SOP：从首响到关闭的四步

工单处理最怕"凭感觉"，一人团队更要 SOP 化，因为你的大脑同时在跑开发、客服、运营三个进程：

1. 首响（First Reply）：复述问题 + 给出下一步。"收到，你说的是导出 CSV 时中文乱码对吗？我先复现一下，有进展在这里同步。"——复述确认避免了"我理解错了"的返工。
2. 升级（Escalate）：15 分钟搞不定的，标记"需深入排查"并给用户一个时间点，而不是憋着。"这个问题比预想的复杂，我需要查一下日志，明天中午 12 点前给你结论。"——给时间点，而不是给希望。
3. 解决（Resolve）：告诉用户"做了什么"，而不是"修好了"。"已修复：导出时强制用 UTF-8 with BOM 编码，Excel 打开不再乱码。"——用户需要的是"原因 + 动作"，这是信任的来源。
4. 关闭与回访（Close & Follow-up）：解决后 48 小时自动发一条 1-5 分满意度评价。评分 ≤2 的自动重开——让不满意的用户有"一键重开"的出口，而不是让他去应用商店打一星。

工单 → 需求池：和反馈闭环的衔接

这里是两条环的交汇点。P4 的"功能建议"和反复出现的 P3（比如 10 个人都问"能不能导出 PDF"），本质上已经不是客服问题，而是产品需求。标准动作：

• 工单打上 feedback 标签，一键转到需求池（可以就是反馈闭环那篇文章里的需求表）。
• 转过去时带上原始工单号和用户原话——需求评审时，"10 个用户原话"比"产品经理觉得"有说服力 10 倍。
• 需求上线后，回到工单里逐一回复当初提需求的用户："你之前提的 PDF 导出上线了。"这是反馈闭环里"告诉用户我们做了"的弹药，而弹药来自工单系统。

所以两条环的关系是：工单系统是"问题"的入口和出口，反馈闭环是"需求"的加工厂。入口统一、加工分开、出口回流——这就是一人团队的客服 + 产品双循环。

自研还是买现成：三个判断标准

做到这一步你会问：上面这些，Crisp / Plain / Intercom 现成的客服工具不都有吗？还要自己写？判断标准有三条：

1. 工单量：每天 < 20 单，自研完全够用，上面的 Prisma 模型 + 一个管理后台页面就是全部；每天 > 50 单，买现成的，别在客服系统上烧开发时间。
2. 定制需求：需要和自家订单/订阅数据深度联动（比如工单里直接看到用户的付费计划），自研更顺；标准客服流程，现成的更稳。
3. 成本：现成工具按坐席/按量收费，用户量涨了客服成本跟着涨；自研是一次性投入。算一笔账就清楚了。

我的观点：先自研最小可用版，跑到每天 30 单以上再评估迁移。因为自研过程中你被迫想清楚了"我的 SLA 是什么、我的分诊规则是什么"——这些认知迁移到任何工具上都管用。而一上来就买最贵的客服套件，等于把"想清楚"的过程外包掉了，最后配出来的还是一套没人用的规则。

模板库：复制即用的四封信

一人团队没时间每封回复都现写，准备四个模板，覆盖 90% 的场景。模板的灵魂是具体——"尽快处理"是废话，"明天下午 6 点前"是承诺：

模板一：建单自动回复

已收到你的反馈，工单 #{{number}}。
我们会在 {{sla_first_reply}} 内首次回复你。
着急的话可以先看看帮助中心，常见问题大多 2 分钟能自己解决。

模板二：需要用户补充信息

感谢反馈！为了更快定位，能麻烦你补充两点吗：
1. 出问题时的操作步骤（点了哪里、输了什么）
2. 浏览器/手机型号 + 一张报错截图
收到后我会立即跟进，工单会保持"待你回复"状态，不会过期。

模板三：升级/延期

跟你同步下进展：这个问题比预想的复杂，涉及到 {{原因一句话}}。
我会在 {{具体时间点}} 前给你结论，期间有任何新发现都会同步在这里。
抱歉让你久等了。

模板四：解决关闭

已解决：{{原因一句话}}，{{动作一句话}}。
你可以 {{验证方法}} 确认一下。
如果还有问题，直接点"重开"就行，不用重新描述。
方便的话花 10 秒打个分 👇（1-5 分）

注意模板四的最后一句：把满意度评价嵌在解决通知里，而不是单独发一封"请评价"的邮件。用户的耐心在问题解决那一刻是最高的，多一封邮件，回复率掉一半。

每周 5 分钟：客服数据复盘

工单系统最大的隐藏价值是数据。每周花 5 分钟看四个数：

• 工单量趋势：环比涨 30%？先看是不是发版引入了新 bug，而不是"用户变多了"。
• 首次响应时间中位数：注意是中位数不是平均数——平均数会被一两个拖很久的单拉偏。中位数超过 SLA 一半，说明人手（就是你）不够了。
• 标签分布 Top5：连续三周 "billing" 标签第一？支付流程该重构了，而不是继续回工单。
• 重开率：重开率 > 15% 说明"解决"的标准有问题——很多单是"自以为解决了"。重开率是最诚实的客服质量指标。

这四个数回答的是同一个问题："客服是在救火，还是在填坑？"救火是正常的，填坑（同一个根因反复烧）是必须停下来修的。没有数据的客服，永远在救火。

三个坑：别在工单系统上翻车

坑一：把工单系统做成公开论坛。有人觉得"公开透明好"，把工单全公开。结果是：用户不敢写真实信息（"我的订单号是…"），你在公开场合还得装作没看见隐私。记住：工单默认私密，想做透明，定期发"本周修复 Top5"公告，效果一样还没风险。

坑二：没有全文搜索。"这个问题上个月好像有人问过"——没有搜索，你就得凭记忆翻。工单标题 + 回复内容建个全文索引（Postgres 的 tsvector 几行配置），新单进来先搜历史，30% 的单能直接复制之前的解法。这是分诊之外的第二时间杠杆。

坑三：附件和工单记录分离。用户在工单里传了截图，你在另一套系统里看；或者附件存在第三方，链接过期了。验收标准：打开一张工单，它的所有上下文（历史回复、附件、内部备注、关联需求）必须在一屏内看完。上下文散落的工单系统，比没有还糟——因为它给了你"我都记下来了"的幻觉。

两周落地计划：从 0 到 1

如果你现在没有任何工单系统，按这个节奏两周上线：

• 第 1-3 天：Prisma 建模（上面的 Ticket/Reply 模型直接抄）+ 管理后台列表页（按状态+优先级筛选，能回复就行）。
• 第 4-5 天：站内表单 + 邮件转工单（去重逻辑别忘了）+ 建单自动回复。
• 第 6-7 天：自动分诊规则 + SLA 四档 + 到期预警 cron。第一周结束，你已经有了一个能用的系统。
• 第 8-10 天：聊天 widget（留言模式）+ 社群机器人引导 + 四个回复模板入库。
• 第 11-14 天：满意度回访 + 每周数据复盘看板 + 全文搜索。补齐体验和数据闭环。

注意顺序背后的逻辑：先让单子"进得来、看得见"（收件箱），再让单子"分得清、不过期"（分诊+SLA），最后才做"体验好、可复盘"（widget+数据）。顺序反了，你会得到一个很好看但漏单的系统。

上线 Checklist

• 统一收件箱：所有渠道进同一个池子，可编号、可分级、可计时
• 工单状态机 6 状态 + 重开机制 + 内部备注隔离
• 自动分诊：关键词路由 + 优先级判定 + 兜底 P3 人工复核
• 建单 10 秒内自动回复：工单号 + 预期时间 + 自助链接
• SLA 四档已定，写进自动回复，cron 做到期预警
• P1 15 分钟无人认领自动叫醒你
• 首响/升级/解决/关闭四步 SOP，升级必须给时间点
• 关闭后 48 小时满意度回访，≤2 分自动重开
• P4/高频 P3 一键转需求池，带用户原话
• 需求上线后回流通知当初提需求的用户

最后回到开头：工单系统不解决客服问题，它让你"看得见"客服问题。而对一人团队来说，看得见的问题，一半已经解决了——因为另一半时间，你都花在到处找消息上。