客户反馈记录、支持工单和投诉记录解决的是三个不同问题：客户说了什么、我们要做什么、不满如何处置。反馈记录原样留存客户表达，范围最宽；支持工单承接需要分派和跟踪的服务请求，是执行单元；投诉记录登记正式不满并支撑处置与回访。本文按客户支持场景说明三者的记录边界、转换条件和回写关系，并区分需求、缺陷、销售线索等相邻对象。
要点总览（TL;DR）
- 客户反馈记录留存客户原话与来源，范围最宽；支持工单承接需要责任人和时限的服务请求；投诉记录登记正式不满并支撑处置与回访。
- 衔接按“先留存、再判断、后升级”进行：信息类表达只记反馈，需要处理时转工单，涉及正式不满或服务承诺时另立投诉记录并关联工单。
- 工单与投诉关闭后要把处理结论、关闭时间和回访结果回写到原反馈记录，形成可追溯的闭环。
- 功能诉求归需求管理、可复现缺陷归缺陷管理、采购意向归销售CRM，客户支持记录只保留来源与转交说明。
- 常见问题是所有反馈都开工单、投诉只写工单备注、反馈只统计不关联，规范做法是统一来源字段、关联字段和关闭条件。
三者的定义与记录范围边界
三类记录的区别首先体现在记录目的上。反馈记录保存客户原话和原始诉求，工单保存处理责任与进度，投诉记录保存不满事实与处置依据。把目的分清，才能判断一条客户表达应该落在哪张表单上。
客户反馈记录：原样留存客户表达
客户反馈记录用于留存客户提出的意见、建议、咨询和问题线索，核心要求是保留来源、时间、客户原话和联系方式。它回答“客户说了什么”，不承担处理进度跟踪。信息类咨询、产品改进建议、暂不需要立即处理的抱怨，都可以先以反馈记录形式保存。反馈记录不记录内部处理方案，也不作为责任分派的依据。
支持工单：需要跟踪到关闭的服务请求
支持工单是服务请求的执行单元，适用于需要受理、分派、处理和跟踪到关闭的事项。一张工单至少包含请求内容、责任人、优先级、处理时限和关闭结论。工单回答“谁在什么时候把这件事处理完”。工单不承担对客户情绪的定性，也不用于统计客户不满程度；客户在工单中表达的不满，应另行登记。
投诉记录：正式不满的登记与处置依据
投诉记录用于登记客户对产品或服务表达的正式不满，并支撑后续处置、责任认定和回访。它记录投诉事由、客户诉求、涉及的产品或服务环节、处置结论和回访结果。投诉记录不替代日常服务请求：设备需要维修，仍要走工单；投诉记录关注的是服务过程和结果是否达到承诺。
| 记录类型 | 记录对象 | 触发条件 | 主要责任角色 | 关闭条件 |
|---|---|---|---|---|
| 客户反馈记录 | 客户原话、意见、建议、问题线索 | 客户任何形式的表达 | 客服或前台受理人员 | 信息登记完整并完成分类 |
| 支持工单 | 需要处理的服务请求 | 需要责任人和处理时限 | 服务台分派人员、处理工程师 | 处理完成并经客户确认 |
| 投诉记录 | 正式不满、责任追究、服务承诺争议 | 客户明确表达不满或要求追责 | 投诉处理负责人、服务管理者 | 处置完成并完成回访 |
从反馈到工单再到投诉的衔接机制
三类记录按“先留存、再判断、后升级”的顺序衔接。客户表达先进入反馈记录，受理人员判断是否需要处理、是否涉及正式不满，再决定转为工单或另立投诉记录。转换动作应留下关联字段，避免同一件事在多张表单中失去联系。
只记反馈的情形
客户提供信息、提出建议、咨询使用方法，或表达的问题暂时不需要安排处理时，保留反馈记录即可。例如客户建议增加报表导出格式，或询问保修期限，登记来源和内容后进入分类统计，不需要开立工单。判断标准是：当前没有明确的服务动作需要分派和跟踪。
转为支持工单的情形
客户表达中包含需要处理的服务请求，且需要明确责任人和处理时限时，应转为支持工单。例如设备需要上门检修、账号需要恢复、订单需要核查。转换时把反馈记录中的客户原话、联系方式和问题描述带入工单，并在两张记录上互相标注编号。工单承接的是处理动作，反馈记录继续保留原始表达。
另立投诉记录的情形
客户明确表达不满、要求追究责任，或争议涉及服务承诺时，应在工单基础上另立投诉记录并建立关联。投诉记录不取代工单，工单继续推进具体处理，投诉记录同步记录处置过程、责任认定和回访安排。若客户的不满只涉及态度问题而没有具体服务请求，也可以只登记投诉记录，并在其中注明关联的反馈来源。
关联与回写
衔接的关键是双向关联和处理结果回写。工单关闭后，把处理结论、完成时间和客户确认情况回写到原反馈记录；投诉记录完成回访后，同样回写处置结果。这样，反馈记录才能从“客户说了什么”扩展为“最后怎么解决”，投诉记录也能为服务改进提供可追溯的依据。回写字段建议固定为处理结论、关闭时间、关联工单号和回访结果，减少人工补录造成的遗漏。
与相邻概念的区分：需求、缺陷与销售线索
客户支持记录容易与需求、缺陷、销售线索混在一起，原因在于同一句客户表达可能同时包含多种信息。区分的原则是按处理对象归属，而不是按客户原话归属。
产品功能诉求归需求管理
客户提出希望产品增加某项功能、调整某个流程，属于产品需求线索。反馈记录可以保留客户原话和来源，但需求评估、优先级排序和立项应在需求管理中完成。反馈记录中直接立项，会让服务团队承担产品决策职责，也会使需求池混入大量未经评估的零散意见。
可复现缺陷归缺陷管理
客户报告软件报错、数据异常，经确认可复现的，应流转到缺陷管理跟踪修复。支持工单保留客户侧受理信息、影响范围和沟通记录，缺陷管理记录复现步骤、修复版本和验证结果。两者通过关联字段连接，工单不替代缺陷的修复流程，缺陷记录也不承担对客沟通。
销售机会归销售CRM
客户在支持过程中透露采购意向、扩容计划或推荐其他部门，属于销售机会，应转交销售CRM跟进。客户支持记录只保留服务相关内容和转交说明，不把商机金额、成交阶段纳入支持表单，避免服务记录承担销售管理职能。
同一表达拆分为多条记录
一条客户来电可能同时包含故障报修、功能建议和对响应速度的不满。此时应拆分为工单、需求线索和投诉记录，并保留共同的来源编号或原始反馈记录。拆分不是重复记录，而是让每类对象由对应角色按各自规则处理，同时保持来源可追溯。
一个完整例子：设备故障投诉如何走完三类记录
以下为演示情景，用于说明三类记录的分工与顺序，不代表特定企业的实际流程。
客户来电描述设备运行时有异响，客服先登记为反馈记录，记录来电时间、客户名称、设备型号、客户原话和联系方式。受理人员判断需要上门检修，将反馈转为支持工单，设定责任工程师和处理时限，工单中带入原反馈编号。
沟通中客户同时表达对上次报修响应速度的不满，并要求给出解释。客服在工单之外另立投诉记录，关联同一张工单和原反馈记录，登记不满事由、客户诉求和承诺的回访时间。工单继续由工程师处理设备问题，投诉记录由服务负责人跟进响应时效的解释和整改。
工程师完成上门检修后，工单记录处理过程和更换部件，经客户确认后关闭。客服把处理结论和关闭时间回写到原反馈记录。投诉记录在完成回访、确认客户接受解释后关闭，并在记录中注明整改措施。至此，一条客户来电形成了反馈、工单、投诉三条关联记录，各自完成关闭。
常见误解与记录规范建议
三类记录用混，通常不是定义不清，而是受理环节图省事，把不同目的的信息塞进同一张表单。以下误解在客户支持团队中较为常见，对应的规范可以直接落到字段和关闭条件上。
误解一：所有反馈都开工单
把咨询、建议、感谢一并开成工单，会让工单数量快速膨胀，优先级判断失去参考价值，工程师时间被大量无需处理的事项占用。规范做法是先登记反馈，按“是否需要责任人和时限”判断是否转工单，信息类表达在反馈记录中完成分类即可。
误解二：投诉只记在工单备注里
投诉信息写在工单备注中，处置责任、回访安排和整改结论缺少独立载体，统计投诉率、分析重复投诉时难以提取。规范做法是另立投诉记录并关联工单，明确投诉负责人、处置时限和回访结果字段。
误解三：反馈记录只做统计不做关联
反馈记录如果只用于数量统计，不记录后续工单号和处理结论，就无法回答“这条意见最后怎么处理”。规范做法是在反馈记录中设置关联工单、关联投诉、处理结论和关闭时间字段，工单和投诉关闭后回写。
可执行的记录规范
- 统一来源字段：每条记录保留来源渠道、客户标识、原始表达和登记时间，拆分记录时共用来源编号。
- 统一关联字段：反馈记录关联工单号和投诉号，工单关联原反馈和缺陷或需求工作项，投诉记录关联工单和回访记录。
- 统一关闭条件：反馈记录以分类完成并回写处理结论为关闭；工单以处理完成并经客户确认为关闭；投诉记录以处置完成并完成回访为关闭。
- 统一角色分工：前台负责登记与判断，服务台负责分派，处理人负责工单结论，服务负责人负责投诉处置与回访。
在工具承载上，ONES Desk 面向企业服务与协作场景，支持通过门户收集工单、分享填写链接收集客户反馈，并通知和反馈工单处理结果；工单可关联到待办事项列表，也可一键关联 ONES Project 的需求或缺陷工作项持续跟踪，相关服务经验可沉淀到 ONES Wiki。对于需要把反馈、工单与后续处理关联起来的团队，可以用工作项关联和状态流转承载上述回写关系；投诉记录的独立登记与回访流程，则需结合团队自身规范在工单字段或工作流中配置。
常见问题
客户在工单里顺带表达不满，是否一定要另立投诉记录？
看不满是否需要独立处置和回访。客户只是对处理进度有情绪、工单继续推进即可解决的，可在工单中记录沟通情况；客户明确要求追责、质疑服务承诺，或需要专门回访给出解释时，应另立投诉记录并关联工单。这样投诉的处置责任、时限和回访结果有独立载体，统计重复投诉时也能提取。
只登记了反馈记录、后来发现需要处理，补开工单时要注意什么？
补开工单时把原反馈编号、客户原话、联系方式和问题描述带入工单，并在反馈记录上标注工单号，保证两边能互相找到。工单关闭后，把处理结论和关闭时间回写到反馈记录。若中间隔了较长时间，建议在反馈记录中注明转工单的日期和判断人，便于回溯响应时效。
一条客户来电同时涉及报修、功能建议和投诉，应该拆成几条记录？
按处理对象拆分：报修转为支持工单，功能建议作为需求线索转交需求管理，投诉另立投诉记录，三条记录共用同一个来源编号或关联同一条原始反馈记录。拆分后各自由对应角色按各自规则处理，来源仍可追溯。不建议把三类信息塞进一张工单，否则处理结论、优先级和统计口径都会混在一起。
投诉记录关闭后，还需要回写反馈记录吗？
需要。投诉记录完成处置和回访后，把处置结论、回访结果和关闭时间回写到关联的反馈记录，反馈记录才能完整呈现“客户说了什么、最后怎么解决”。如果投诉是在工单基础上另立的，工单和投诉两条线的结论都应回写，避免反馈记录只保留最初的原话。
用工具承载这三类记录时，重点看哪些配置能力？
重点看三处：一是能否通过门户或填写链接收集客户反馈并保留来源；二是工单能否关联需求、缺陷等工作项，把处理动作接续下去；三是字段和工作流能否自定义，以承载投诉的处置、回访和关闭条件。以 ONES Desk 为例，其官网介绍支持门户收集工单、分享填写链接收集客户反馈，工单可关联 ONES Project 的需求或缺陷工作项，也可关联 ONES Wiki 沉淀服务经验；投诉记录的独立登记与回访流程需结合团队规范在字段或工作流中配置。
