客户反馈记录、客户支持工单和投诉记录是客户支持场景中三个不同层级的记录对象：反馈记录范围最宽，保存客户表达本身；工单是为解决具体请求而建立、带责任人和处理状态的流转单元；投诉记录是反馈中表达不满、要求纠正或赔偿的一类，需要单独标记和升级。三者可以相互转化，ONES Desk 等工单管理工具可承载其中的处理与关联动作。
要点总览（TL;DR）
- 客户反馈记录保存客户表达本身，范围最宽；客户支持工单是带责任人和处理状态的可流转单元；投诉记录是反馈中表达不满、要求纠正或赔偿的子集。
- 判断一条信息落在哪：需要有人跟进并给出结果就建工单，客户明确表达不满并要求答复就标记投诉，两个条件可以同时成立。
- 三者不是选一个用，而是同一条服务链路上的不同环节：反馈留存原始信息，投诉标记风险与时限，工单承载处理过程与结论。
- 反馈记录侧重来源、客户、时间与原话摘要；工单侧重编号、优先级、责任人、状态与解决记录；投诉在此基础上增加严重程度、诉求、时限与回访结果。
- 工单量小的团队可用标签标记投诉，工单量大且有明确服务时限承诺的团队更适合独立工作项类型与升级流程。
三者的核心区别一句话说清
如果只记一句话：客户反馈记录是“客户说了什么”，客户支持工单是“谁在什么时候把它处理到什么程度”，投诉记录是“客户不满意、要求给说法的那部分反馈”。三者的范围关系是：反馈记录最宽，投诉记录是反馈记录的子集，工单则是从记录中派生出来的处理单元，同一件事可能同时出现在三类记录里。
判断一条信息该落在哪，可以看两个条件：是否需要有人跟进并给出结果，是则建工单；客户是否明确表达不满、要求纠正或正式答复，是则标记为投诉。两个条件可以同时成立，一条投诉通常既需要标记，也需要建单处理。
| 对比维度 | 客户反馈记录 | 客户支持工单 | 投诉记录 |
|---|---|---|---|
| 定位 | 客户意见、建议、评价的原始留存 | 为解决某个具体请求而建立的处理单元 | 反馈中表达不满、要求纠正或赔偿的特殊类别 |
| 触发条件 | 客户通过任一渠道表达意见即可形成 | 存在需要跟进解决的具体请求 | 客户表达不满并提出纠正、赔偿或正式答复要求 |
| 是否带处理状态 | 通常不带，以留存为主 | 带状态，如待分派、处理中、已解决、已关闭 | 本身是标记，处理状态由关联工单承载 |
| 是否有责任人 | 一般无固定责任人 | 有明确责任人和协作人 | 有回访责任人，处理责任随工单分派 |
| 范围关系 | 最宽，覆盖所有客户表达 | 从反馈或直接提交中派生 | 反馈记录的子集 |
| 典型使用角色 | 客服、运营、产品、销售助理 | 客服、技术支持、服务经理 | 客服主管、服务经理、质量或客诉专员 |
这张表说明的是定位差异，不意味着三者只能选一个使用。实际工作中，一条客户意见往往先进入反馈记录，再按需转为工单，投诉则在反馈记录上打标并升级，三者共同构成一条可追溯的服务链路。
客户反馈记录：记录什么、不记录什么
客户反馈记录的核心任务是保存客户表达本身，让团队知道“客户原话是什么、从哪来、什么时候说的”。它回答的是信息留存问题，不承担分派和解决职责。因此，反馈记录可以来自售后回访意见、产品评价、功能建议、咨询问题、抱怨，也可以来自客服在沟通中听到的零散评价。
一份可用的反馈记录，字段不必复杂，但要能支撑后续检索和判断。常见字段包括：
- 来源渠道：电话、在线客服、邮件、回访、问卷、门户提交等；
- 客户信息：客户名称、联系人、所属产品线或服务合同；
- 时间：客户表达的时间，以及记录人录入的时间；
- 原话摘要：尽量保留客户表述的关键内容，避免只写结论；
- 关联对象：涉及的产品、订单、服务记录或历史工单编号；
- 初步分类：咨询、建议、评价、抱怨等，便于后续筛选。
反馈记录不包括内部处理步骤、责任分派和解决结论。这些内容属于工单的范畴，如果混写进反馈记录，记录会变成处理日志，原始信息反而被淹没。同样，反馈记录与销售线索、营销活动名单有边界：客户表达购买意向属于线索管理，反馈记录关注的是客户对产品、服务或体验的意见，两者可以关联，但归档口径不同。
客户支持工单：从记录到可流转的处理单元
工单的本质是一个可流转的处理单元。它把“客户提出了什么”转化为“谁负责、做到哪一步、什么时候完成”。一条反馈记录可以只停留在留存层面，工单则必须有人接手、有状态变化、有解决结论，这是两者最实质的差别。
一张完整的工单通常包含以下组成：
- 工单编号：唯一标识，便于引用和追溯；
- 请求描述：客户问题的具体内容，可引用来源反馈记录；
- 优先级：依据影响范围和紧急程度确定；
- 责任人：当前处理人及协作人；
- 状态：待受理、处理中、待客户确认、已解决、已关闭等；
- 解决记录：处理过程、解决方案、客户确认结果。
工单的生命周期一般从创建开始，经过分派、处理、解决，到关闭结束。工单的来源有两类：一类由反馈记录转化而来，客服在整理反馈时判断需要跟进，即建单处理；另一类由客户直接提交，例如通过服务门户填写表单，系统直接生成工单。工单关闭时回填的解决信息，可以反哺到原反馈记录中，让这条记录从“客户说了什么”扩展为“客户说了什么、后来怎么解决的”，为后续分析和回访提供完整依据。
投诉记录：反馈中的特殊一类
投诉记录不是独立于反馈之外的另一套台账，而是反馈记录中需要特别关注的一类。判定一条反馈是否构成投诉，关键看客户是否表达了不满，并明确提出纠正、赔偿或正式答复的要求。仅仅提出问题是咨询，仅仅表达失望是普通负面反馈，明确提出“要求处理”“要求赔偿”“要求给个说法”，才进入投诉范畴。
由于投诉涉及服务承诺和客户关系风险，记录时需要增加专属字段：
- 严重程度：一般投诉、重要投诉、重大投诉，用于确定响应级别；
- 客户诉求：退款、换货、维修、书面答复、赔偿等具体诉求；
- 时限要求：客户期望的答复时间或内部服务承诺时限；
- 回访结果：处理后的客户确认情况、满意度、是否再次投诉；
- 升级记录：升级到哪一级、由谁审批、处理结论。
投诉通常触发升级流程，形成工单或专项处理任务，由主管或客诉专员介入。它与普通反馈记录共用同一套留存口径，即原始表达、来源、时间都要完整保留，区别在于多了标记、时限和回访要求。团队规模较小时，可以用标签在反馈记录上标记投诉；工单量大、有明确服务时限要求的团队，更适合设置独立的工作项类型和升级规则。
三者如何衔接：一条客户意见的完整走向
下面用一个演示情景说明三者的转化关系。某客户在售后回访中反映，购买的配件到货即损坏，要求更换并补偿延误损失。
第一步，客服把这次回访内容录入反馈记录：来源为售后回访，客户信息、时间、原话摘要、关联订单齐全。此时它只是一条记录，还没有责任人。
第二步，客服判断客户明确表达不满并提出更换和补偿要求，符合投诉判定条件，于是在该记录上标记投诉，补充严重程度、诉求和答复时限。
第三步，客服依据这条记录创建支持工单，填写请求描述、优先级和责任人，工单进入分派和处理流程。投诉标记与工单编号相互关联，后续查询任一对象都能找到另一条。
第四步，工单处理完成后，处理结论和客户确认结果回填到工单，同时更新原反馈记录的回访结果字段。至此，这条客户意见完成了从留存、标记、处理到回访的闭环。
围绕这个流程，有三种常见误解需要纠正：
- 把工单当反馈台账：只建单不留存原始表达，事后分析客户意见时缺少原话和来源，无法判断问题分布；
- 把投诉混在普通反馈里不升级：投诉没有时限和回访要求，容易错过响应窗口，客户不满升级；
- 反馈记录只记不处理：记录堆积却无人判断是否需要建单，客户意见停留在纸面，服务改进缺少输入。
在ONES中如何承载这三类记录
把三类记录落到工具里，关键是根据管理动作选择承载方式：原始信息需要留存，处理请求需要流转，投诉需要标记和回访。ONES Desk 是面向企业服务与协作场景的工单管理产品，可统一受理、分派、处理和跟踪客户反馈与服务事项，适合承载这条链路中的处理环节。
反馈记录的原始信息，可以用文档或轻量工作项留存，重点保存来源渠道、客户、时间和原话摘要。需要客户直接提交意见时，ONES Desk 支持通过门户分享填写链接收集客户反馈，并直接与客户对话、通知处理结果，减少信息在多个渠道间转述的损耗。
支持工单用工作项承载，通过自定义工单属性和工单内容适配不同角色的收集需求与不同场景，配合可调整的工作流和优先级设置，让工单按团队实际方式分派和流转。工单处理过程中，可一键关联到 ONES Project 的需求或缺陷工作项持续跟踪，也可关联 ONES Wiki 页面沉淀问题分析与服务经验。
投诉记录可以在工单或反馈工作项上用标签或独立工作项类型标记，补充严重程度、诉求、时限和回访结果字段，便于按条件筛选出待回访的投诉。反馈记录、投诉标记与处理工单之间通过关联关系串联，形成从客户表达到处理结论的可追溯链路。团队可根据工单量和时限要求选择标记方式：量小用标签，量大且有时限承诺时设置独立类型和升级流程。
常见问题
客户只提了一个问题、没有表达不满，需要建工单吗？
看这个问题是否需要有人跟进并给出结果。客户咨询产品用法、询问订单进度这类请求，虽然不构成投诉，但只要需要专人答复或操作，就适合建工单，让责任人和状态清晰可查。如果只是客户随口评价、暂时无需回应，留在反馈记录中即可，后续分析时再判断是否转化为工单。
投诉处理完成后，投诉记录还需要保留吗？
需要保留。投诉记录承载的是客户诉求、时限承诺和回访结果，这些信息在工单关闭后仍有价值：一方面用于回访确认客户是否满意，另一方面用于统计投诉分布、复盘服务问题。建议在工单关闭时把处理结论和客户确认结果回填到投诉记录，形成完整闭环，而不是随工单关闭一并归档消失。
反馈记录和工单能不能合并成一套台账管理？
可以放在同一套工具里管理，但两类信息的字段和用途不同，合并成一张表容易让原始表达被处理日志淹没。较稳妥的做法是分开承载、相互关联：反馈记录保留客户原话与来源，工单记录处理过程与结论，通过关联字段互相引用。这样既能统一检索，又不会在工单流转中丢失客户原始意见。
团队规模小、工单量不大，投诉还需要单独建类型吗？
不一定。工单量小、投诉数量有限的团队，用标签在反馈记录或工单上标记投诉，配合严重程度和回访结果字段，通常足以支撑筛选和跟踪。当投诉量上升、出现明确的服务时限承诺，或者需要按投诉级别触发不同审批和升级路径时，再考虑设置独立的工作项类型和升级规则，避免一开始就引入过重的流程配置。
客户在工单处理过程中又提出新意见，应该记在哪里？
新意见如果与当前工单的请求直接相关，例如对处理方案的补充说明，可以更新到工单描述或处理记录中；如果属于新的问题或独立评价，建议另建一条反馈记录并关联原工单编号。这样既保持原工单的处理边界清晰，又不会遗漏客户后续表达，事后分析时也能看到同一客户在不同时间点的意见变化。
