客户反馈是否需要转成支持工单，取决于它是否需要跨角色跟进、有明确责任人和处理时限、需要过程记录与闭环；是否需要另建投诉记录，则取决于反馈是否指向服务态度、交付质量、承诺未兑现等不满，以及客户是否要求正式答复、追责或补偿。三类记录可以并存：反馈记录保留原貌，工单承载处理过程，投诉记录承载定级、答复与回访。
要点总览（TL;DR）
- 客户反馈记录是客户意见的原始登记，本身不承诺处理时限；支持工单是带责任人、状态和时限的处理单元；投诉记录是对不满事项的正式登记，附带定级、答复与回访要求。
- 当反馈需要跨角色协作、客户期待明确答复、问题需要过程记录与状态跟踪，或存在服务时限与 SLA 承诺时，应转为支持工单。
- 当反馈指向服务态度、交付质量、承诺未兑现等不满，且客户要求正式答复、追责或补偿时，应在工单之外另建投诉记录。
- 三类记录可以并存：反馈记录保留原貌，工单承载处理过程，投诉记录承载定级、答复与回访，通过关联字段保持同一条线索。
- 表扬、随口评价、已当场解答的咨询留在反馈记录即可；重复反馈应归并到主记录，转单后原反馈保留并标注去向。
客户反馈记录、支持工单与投诉记录分别指什么
三类记录都来自客户声音，都可以关联到同一客户和同一事项，但承担的管理任务不同。先把对象边界分清，后面的转单判断才有依据。
| 记录类型 | 核心定义 | 关键字段 | 主要用途 |
|---|---|---|---|
| 客户反馈记录 | 客户意见的原始登记，保留客户说了什么、什么时候说的、从哪里来的 | 来源渠道、反馈内容、发生时间、客户信息、原始描述 | 信息留存、分类分析、作为后续处理的原始依据 |
| 支持工单 | 带责任人、状态和处理时限的处理单元 | 责任人、优先级、状态、时限、处理记录、关联反馈 | 推动问题解决，记录处理过程，向客户答复结果 |
| 投诉记录 | 对客户不满事项的正式登记，附带定级、答复与回访要求 | 投诉级别、不满事项、客户诉求、答复人、答复时限、回访结果 | 正式回应不满，明确追责与补偿口径，完成回访闭环 |
三者的共同点是同源：一条客户反馈可以同时关联一张支持工单和一条投诉记录，客户信息与事项描述保持一致，避免客户在不同渠道重复陈述。区别在于承诺强度：反馈记录本身不承诺处理时限，工单承诺有人负责并在时限内推进，投诉记录则额外承诺正式答复与回访。
三者的边界：哪些内容留在反馈记录里
相当一部分客户反馈只需要登记和留存，不需要转成工单，更不需要建投诉记录。判断口径是：这条反馈是否需要有人对它做出答复或采取处理动作。如果答案是否定的，留在反馈记录里即可。
典型情形包括：客户对产品或服务表达的表扬、随口评价、使用感受；客户提出的改进建议，尚未进入产品评估；客户咨询中已经当场解答完毕、无需后续跟进的问题。这些内容的价值在于汇总分析客户声音，而不是逐条推动处理。
重复反馈需要合并处理。同一客户或不同客户就同一事项反复提交的反馈，应归并到同一条主记录或同一张工单下，保留各次提交的时间和渠道，避免同一问题被拆成多张工单、多个责任人重复处理。合并时保留原始描述，不做删改。
已经明确归销售 CRM 或营销运营管理的内容，例如商机跟进、合同条款沟通、市场活动报名，不纳入客户反馈记录体系。具体软件缺陷的流转与修复归缺陷管理承接，本文只讨论反馈在支持工单与投诉记录之间的判断，不展开缺陷修复流程。
什么情况下客户反馈要转成支持工单
转工单的核心信号是：这条反馈需要有人负责、在时限内推进，并给客户一个明确结果。满足以下任一条件，就应当从反馈记录转为支持工单。
- 需要跨角色协作或专业处理。问题超出首次受理人的处理范围，需要技术、交付、财务等角色介入，靠口头转达容易丢失信息。
- 客户期待明确答复或解决结果。客户在反馈中提出了具体问题、明确询问处理进度，或表达了“希望尽快解决”的诉求。
- 问题可复现，需要过程记录与状态跟踪。问题有复现步骤、影响范围，处理过程需要留下排查记录，状态需要从受理推进到解决。
- 存在服务时限或 SLA 承诺。合同或服务协议对响应时间、解决时间有约定，必须有工单承载时限计算与超时提醒。
转单时需要把关键信息一并带过去，避免客户二次描述：客户信息与联系方式、反馈来源渠道、原始描述（保留客户原话）、客户期望结果、已做过的初步沟通。原始描述建议以引用或附件形式保留，处理人在工单内补充排查记录，两者不混写。
什么情况下要另建投诉记录
投诉记录与普通工单的触发差异在于：工单解决“问题是什么、怎么处理”，投诉记录解决“客户为什么不满、如何正式回应”。当反馈同时具备不满指向和正式诉求时，应在工单之外另建投诉记录。
不满指向通常集中在三类：服务态度，例如响应冷漠、沟通中断；交付质量，例如交付物不符合约定标准；承诺未兑现，例如承诺的时间、范围、补偿没有落实。客户明确表达投诉意愿，或提出追责、补偿、书面答复等诉求，是建投诉记录的直接信号。
投诉记录需要承载工单不覆盖的管理动作：按影响范围和客户等级定级，指定专人答复，约定答复时限，处理完成后安排回访并记录客户满意度。投诉记录与支持工单并存时，用关联字段互相指向：投诉记录关联对应工单，工单内标注投诉编号，两边状态同步更新，避免答复口径不一致。
升级与关闭的基本规则可以这样设定：投诉在答复时限内未解决，或客户对首次答复不满意，升级到更高层级处理并重新约定时限；关闭条件包括客户确认接受处理结果、补偿方案执行完毕、回访完成，三者缺一不可。仅完成工单处理但未回访的投诉，不视为关闭。
从反馈到工单、投诉的流转机制
一条反馈从登记到关闭，通常经过受理、判断、转单或建投诉、处理、答复、回访、关闭几个环节。每个环节都有明确的角色和字段，状态才能连续衔接。
- 受理。首次接触客户的角色登记反馈记录，填写来源、内容、时间、客户信息，保留原始描述。
- 判断。受理人或支持主管按前述条件判断：留在反馈记录、转支持工单、还是同时建投诉记录。判断结论和依据写入记录，便于复盘。
- 转单或建投诉。转工单时指定责任人、优先级和时限；建投诉记录时完成定级、指定答复人、约定答复时限，并与工单建立关联。
- 处理。责任人在工单内推进处理，更新状态和处理记录；涉及跨部门时通过关联工作项把任务传递出去，处理结果回写到工单。
- 答复。按约定渠道向客户答复处理结果；投诉记录额外要求正式答复，答复内容与工单结论保持一致。
- 回访与关闭。投诉记录在答复后安排回访，确认客户接受结果；工单在客户确认或时限到期后关闭，反馈记录保留原貌并标注最终去向。
关联字段是流转的关键：反馈记录保存工单编号和投诉编号，工单保存来源反馈编号和投诉编号，投诉记录保存对应工单编号。重复反馈归并到已有工单时，在新反馈上标注主记录编号；误转的工单可以退回反馈记录或合并到正确工单，退回时保留转单记录和原因，不删除历史操作。
在工具承载上，ONES Desk 面向客户反馈与服务事项场景，支持通过门户分享填写链接收集客户反馈，工单可分派、处理并直接与客户对话反馈处理结果；工单可关联到待办事项列表，也可一键关联 ONES Project 的需求或缺陷工作项，便于服务团队与研发团队交接同一条反馈的处理进展。投诉定级与回访若需要独立字段，可通过自定义工单属性与工作流配置来承载，具体配置方式以实际产品能力为准。
和相邻概念的区别：反馈、工单、投诉、缺陷、需求
这几个对象容易混用，用同一口径对照可以看清各自承接什么。
| 对象 | 承接内容 | 与相邻对象的区别 |
|---|---|---|
| 反馈 | 客户意见的原始登记 | 是原始记录，不承诺处理时限；可转为工单或投诉，也可仅留存 |
| 工单 | 带责任人、状态、时限的处理单元 | 承载处理过程；投诉在此之上增加不满定级与正式答复 |
| 投诉 | 不满事项的正式登记与回应 | 关注客户为什么不满、如何答复与回访，处理动作仍由工单承载 |
| 缺陷 | 软件问题的流转与修复 | 由缺陷管理承接，工单可关联缺陷工作项跟踪修复进度 |
| 需求 | 产品建议的评估与排期 | 客户建议先留在反馈记录，经评估后进入需求池，不直接开工单 |
区分的关键是看这条内容最终要产出什么：产出信息留存，留在反馈；产出问题解决，转工单；产出正式回应，建投诉；产出代码修复，进缺陷管理；产出产品规划，进需求池。同一事项在不同阶段可以先后进入多个对象，通过关联字段保持一条线索。
具体例子与常见误解
用三个例子验证前面的判断规则。
例一：客户反映登录失败。客户通过门户提交“账号登录一直报错”，附有报错截图和复现步骤。这条反馈可复现、需要技术排查、客户期待解决，应转为支持工单，指定技术责任人并设定响应时限；原反馈记录保留，工单内关联反馈编号，处理完成后在工单内答复客户。
例二：客户投诉交付延期并要求书面答复。客户指出项目交付比合同约定晚了两周，要求书面说明并讨论补偿。这属于承诺未兑现的不满，且客户明确提出正式答复诉求，应在处理交付问题的工单之外另建投诉记录，完成定级、指定答复人、约定答复时限，处理结束后安排回访。工单与投诉记录互相关联，答复口径保持一致。
例三：客户提出产品建议。客户建议增加批量导出功能，没有提出故障或不满。这条建议留在反馈记录，标注建议类别，定期汇总后提交需求评估；评估通过后进入需求池，不为此开支持工单，也不建投诉记录。
常见误解有三个。其一，认为所有反馈都要开工单，结果是工单量膨胀、真正需要处理的问题被淹没；判断标准应是是否需要有人负责并在时限内给出结果。其二，认为投诉必须单独建一套系统，实际上投诉记录与工单可以在同一套工单体系中用不同类型、不同字段和流程区分，关键是定级、答复、回访字段是否齐全。其三，认为转单后原反馈可以删除，实际上反馈记录是原始依据，转单后应保留并标注去向，便于追溯客户原话和判断过程。
常见问题
客户只是表达不满，但没有提出具体诉求，需要建投诉记录吗？
可以先判断不满指向是否明确。如果客户只是情绪表达，没有说明具体事项，也没有要求答复、追责或补偿，通常先留在反馈记录，由受理人补充沟通、确认事实后再决定是否转工单或建投诉记录。若不满指向服务态度、交付质量或承诺未兑现，即使客户没有主动提诉求，也建议按投诉记录登记，完成定级并安排正式答复，避免不满累积。
一条反馈已经转了工单，后来客户又提出投诉，原来的工单要重新建吗？
不需要重建。保留原工单继续处理具体问题，另建投诉记录并关联该工单，投诉记录承载定级、答复人和答复时限，工单内标注投诉编号。两边状态同步更新，答复口径保持一致。这样客户不需要重复描述问题，处理过程也有完整记录。
同一客户在不同渠道反复提交同一问题，应该怎么处理？
应归并到同一条主记录或同一张工单下，保留各次提交的时间、渠道和原始描述，在新提交上标注主记录编号。归并后由同一责任人统一处理并答复，避免同一问题被拆成多张工单、多个责任人重复处理。归并时保留原始描述，不做删改，便于后续追溯客户原话。
投诉记录关闭需要满足哪些条件？
通常需要同时满足三个条件：客户确认接受处理结果、补偿方案执行完毕、回访完成并记录结果。仅完成工单处理但未回访的投诉，不视为关闭。如果投诉在答复时限内未解决，或客户对首次答复不满意，应升级到更高层级处理并重新约定时限。
用一套工单系统同时管理反馈、工单和投诉，可行吗？
可行。关键不在于是否单独建系统，而在于投诉所需的定级、答复人、答复时限、回访结果等字段是否齐全，以及工单与投诉记录之间能否互相关联。通过工单类型、自定义属性和工作流区分不同记录，可以让三类对象在同一套体系中衔接，减少客户重复陈述和信息分散。ONES Desk 支持自定义工单属性与工作流配置，工单也可关联 ONES Project 的需求或缺陷工作项，便于服务团队与研发团队交接同一条反馈的处理进展。
