客户反馈记录要能支撑三件事：复现客户遇到的问题、追溯内部处理过程、向客户交代结论。围绕这三点，记录至少保留六类信息：来源与联系人、时间与渠道、问题或诉求的原始描述、涉及的产品与订单信息、处理过程与责任角色、结论与客户确认。下面给出字段清单、填写步骤、角色分工、完整示例和检查清单，可按团队的支持场景增减字段。
要点总览（TL;DR）
- 客户反馈记录至少保留六类信息：来源与联系人、时间与渠道、原始描述、产品与订单信息、处理过程与责任角色、结论与客户确认，底线是能复现问题、能追溯处理、能向客户交代。
- 字段按生命周期分步填写：受理录入原始描述与附件，分类定级补产品版本与影响范围，处理中逐次留痕对外回复，关闭时写清结论与客户确认方式。
- 职责按“谁最接近信息源谁填、谁对结论负责谁复核”划分：一线受理人管原始信息，技术支持管技术字段，客服主管复核定级与关闭，产品/研发接口人提供关联工作项与原因说明。
- 记录质量靠固定检查项维持：必填完整、描述可复现、结论逐条回应诉求、确认方式与时间可查、关联工作项状态同步；敏感信息在字段层面限定可见范围并脱敏。
- 字段增删需评审发布并保留版本记录，规范建议每半年结合检查结果复审一次。
一份客户反馈记录的最小字段清单
字段设计的目标是让一条记录在无人口头补充的情况下也能被读懂。六类信息分别承担不同作用：来源与联系人解决“谁在反馈”，时间与渠道解决“什么时候从哪里来”，原始描述解决“客户到底说了什么”，产品与订单信息解决“涉及哪个对象”，处理过程解决“谁做了什么”，结论与确认解决“最后怎么答复、客户是否认可”。
| 字段名 | 所属分组 | 必填性 | 填写说明 |
|---|---|---|---|
| 反馈编号 | 来源与联系人 | 必填（系统生成） | 唯一标识，用于跨记录引用和后续检索 |
| 客户名称 | 来源与联系人 | 必填 | 填写正式客户名称，与合同或账号主体一致 |
| 联系人及联系方式 | 来源与联系人 | 必填 | 记录反馈人姓名、职务和可回访的联系方式 |
| 反馈来源 | 来源与联系人 | 必填 | 区分客户直接反馈、内部转交、合作伙伴转达等 |
| 受理时间 | 时间与渠道 | 必填 | 记录首次接收到反馈的时间，精确到分钟 |
| 反馈渠道 | 时间与渠道 | 必填 | 电话、邮件、在线表单、即时通讯、现场拜访等 |
| 原始描述 | 原始描述 | 必填 | 尽量保留客户原话，附截图、日志或附件；转述时标注“转述” |
| 问题或诉求类型 | 原始描述 | 必填 | 按团队约定分类，如使用咨询、功能异常、服务投诉、需求建议 |
| 影响范围 | 原始描述 | 选填 | 受影响的人数、业务环节、是否影响正常使用 |
| 产品名称与版本 | 产品与订单信息 | 必填（涉及具体产品时） | 写明产品、模块和版本号，便于复现 |
| 订单号或合同号 | 产品与订单信息 | 选填 | 涉及费用、服务期限、履约争议时必填 |
| 环境信息 | 产品与订单信息 | 选填 | 操作系统、浏览器、部署方式等复现所需条件 |
| 优先级 | 处理过程 | 必填 | 按影响范围和紧急程度定级，写明定级依据 |
| 责任人 | 处理过程 | 必填 | 当前处理人，转交时更新并保留转交记录 |
| 处理进展 | 处理过程 | 必填 | 按时间顺序记录每次动作、结论和对外回复内容 |
| 关联记录 | 处理过程 | 选填 | 关联的需求、缺陷、知识文档或其他工单编号 |
| 处理结论 | 结论与确认 | 必填 | 说明问题原因、解决方式或不予处理的理由 |
| 客户确认 | 结论与确认 | 必填 | 记录客户是否认可结论、确认时间和确认方式 |
| 后续动作 | 结论与确认 | 选填 | 回访计划、补偿安排、需求跟进等未完结事项 |
字段命名要统一，避免同一含义出现多种写法。例如“反馈渠道”就不要再混用“来源渠道”“进线方式”；“优先级”统一使用高、中、低三档并附定级标准。填写口径也要写进规范：时间统一使用同一时区，产品版本写到具体版本号，原始描述与处理意见分栏存放，不把内部判断写进客户原话栏。
从接收到关闭：记录的填写步骤
字段清单是静态的，填写过程按反馈的生命周期推进。每一步都有明确的输入、动作、输出和完成标志，避免记录在某个环节停住。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 受理录入 | 客户来电、邮件、表单或转交信息 | 录入客户名称、联系人、反馈渠道、受理时间和原始描述，上传截图或附件 | 一条待分类的反馈记录 | 原始描述可独立阅读，附件齐全 |
| 分类与定级 | 已录入的原始描述 | 补充问题类型、产品与版本、订单信息、影响范围，按标准确定优先级 | 分类定级完成的记录 | 类型、优先级、影响范围三项已填，定级有依据 |
| 分派与处理 | 分类定级后的记录 | 指定责任人，处理过程中逐次记录动作、进展和对外回复，需要跨部门时关联对应工作项 | 带处理轨迹的记录 | 每次对外回复都有时间点和内容，责任人变更可追溯 |
| 关闭与确认 | 处理完成的记录 | 填写处理结论，向客户说明并取得确认，登记后续动作 | 已关闭的完整记录 | 结论、客户确认、后续动作三项已填，状态置为关闭 |
受理环节最容易出问题的是原始描述。客户说“系统用不了”，直接照抄无法复现，受理人应追问操作步骤、报错信息和发生时间，把追问结果补充在原话之后，并标明哪些是客户原话、哪些是受理人补充。分类定级环节要防止凭感觉定优先级，影响范围字段就是定级的依据。处理环节的记录要求是“每次对外回复都留痕”，客户中途询问进展的答复也属于处理过程的一部分。关闭环节不能只写“已解决”，要写清原因和解决方式，客户确认可以是邮件回复、电话口头确认加记录人签字，方式本身也要写进字段。
谁在什么环节填哪些字段
字段无人填和多人重复填，通常都是职责没分清。按角色划分字段职责时，把握一条原则：谁最接近信息源，谁负责填写；谁对结论负责，谁负责复核。
| 角色 | 负责字段 | 填写时点 | 交付物 |
|---|---|---|---|
| 一线受理人 | 客户名称、联系人、反馈来源、受理时间、反馈渠道、原始描述、问题类型 | 受理当时 | 可独立阅读的原始记录及附件 |
| 技术支持 | 产品与版本、环境信息、影响范围、处理进展、关联记录 | 分类定级及处理过程中 | 可复现的技术信息与处理轨迹 |
| 客服主管 | 优先级复核、处理结论审核、客户确认 | 定级时与关闭前 | 定级依据确认、关闭审核意见 |
| 产品/研发接口人 | 关联需求或缺陷编号、技术原因说明 | 需要跨部门处理时 | 关联工作项及原因结论 |
原始描述与处理结论的边界要写清楚：原始描述栏只放客户表达的内容和受理人的追问补充，处理人的分析、判断和内部沟通记录放在处理进展栏。两者混在一起，后续复盘时无法区分客户诉求和内部推测。交接时，原责任人更新责任人字段并写明交接原因，接手人从处理进展中了解上下文，不需要口头补课。复核由客服主管在关闭前完成，重点看结论是否回应了原始描述中的每一个诉求点。
当反馈记录以工单形式在系统中流转时，字段、状态和责任人可以由系统承载。ONES Desk 支持自定义工单属性与工单内容，适配不同的收集场景；工单可关联到待办事项列表，打通服务团队与研发团队的协同；也可一键关联到需求、缺陷工作项或知识页面，便于持续跟踪和沉淀经验。上述能力对应企业版时以企业版描述为准，具体预置字段需在实施时按本文清单自行设计。
示例：一条完整的客户反馈记录
以下为演示情景，用于说明字段如何填写，不代表真实客户案例。
背景与原始描述。某制造企业客户通过在线表单提交反馈：财务人员在月末对账时，报表页面加载超过两分钟仍未显示，刷新后出现空白页。客户原话为“每个月末都这样，耽误结账”。受理人追问后补充：浏览器为常用版本，近三个月月末均出现，影响财务组五人。附件为页面截图和提交时间。
分类、定级与处理过程。问题类型定为功能异常，产品与版本填写为报表模块及对应版本号，影响范围记为财务组五人、月末结账环节受阻，优先级定为高，依据是影响核心业务且具有周期性。技术支持排查后确认与数据量增长有关，将工单关联到对应缺陷工作项，并在处理进展中记录：首次回复客户说明排查方向；次日同步临时规避方式；第三日确认修复方案与上线时间。每次回复均记录时间和内容。
结论、客户确认与关联记录。处理结论写明原因、修复版本和规避方式；客户通过邮件确认问题已解决，确认时间和方式记入客户确认栏；后续动作登记为下月月末回访一次。关联记录栏填写缺陷编号和一篇排查经验文档，供同类反馈参考。
记录质量检查与维护
单条记录合格不代表整体可用，需要固定的检查项和字段维护机制。检查可以按以下清单逐项核对：
- 必填项完整性：六类信息对应的必填字段无空缺，选填字段在触发条件下已填写，如涉及费用时订单号不为空。
- 描述可复现性：仅凭原始描述、产品版本和环境信息，另一位同事能还原客户遇到的现象。
- 结论可追溯性：处理结论回应了原始描述中的每个诉求点，处理进展中的每次对外回复都有时间记录。
- 确认有效性：客户确认栏写明确认方式与时间，口头确认有记录人。
- 关联完整性：跨部门处理的事项已关联对应工作项，关闭时关联状态同步更新。
敏感信息处理要在字段层面约定：联系方式、订单金额等字段限定可见范围，导出和共享时按需脱敏，原始描述中的账号、身份证号等信息在录入时即做遮蔽。字段增删不宜由个人随手改动，新增字段需说明用途、必填性和填写口径，经客服主管与系统管理员评审后发布，并保留字段版本记录，历史记录的旧字段值继续可查。字段规范建议每半年结合检查结果复审一次，把高频空缺或口径混乱的字段列为重点修订对象。
常见问题
客户只给了一句模糊描述，原始描述字段该怎么填才不影响后续处理？
原始描述栏保留客户原话，同时在原话之后补充受理人的追问结果，并标明哪些是客户原话、哪些是追问补充。追问至少覆盖操作步骤、报错信息、发生时间和影响范围，让另一位同事仅凭这条记录就能还原现象。追问不到的信息先留空并注明“待客户补充”，不要用推测填空。
反馈涉及费用争议或服务期限时，哪些字段会从选填变成必填？
订单号或合同号平时为选填，一旦反馈涉及费用、服务期限、履约争议，就应转为必填，并同时补齐客户名称与联系人，确保记录能对应到具体合同主体。处理结论中要写明依据的条款或订单信息，客户确认栏记录确认方式与时间。若争议需要跨部门处理，关联记录栏同步填写对应工作项编号。
客户中途多次询问进展，这些沟通要不要都记进处理进展？
要记。处理进展按时间顺序记录每次动作、结论和对外回复内容，客户中途询问进展的答复也属于处理过程。这样关闭时能核对客户提出的每个诉求是否都有回应，复盘时也能看清响应节奏。记录时写明时间点和回复要点即可，不必粘贴完整对话。
口头确认算不算客户确认？字段里怎么写才可追溯？
口头确认可以作为客户确认，但要在客户确认栏写明确认方式、确认时间和记录人，必要时补一条内部备注说明确认场景。邮件回复可直接留存原文或摘要。无论哪种方式，确认内容要对应处理结论中的关键点，避免只写“客户已同意”这类无法核对的表述。
反馈记录用表格或文档管理，和放进工单系统流转，字段设计上有什么差别？
字段清单本身可以通用，差别在于承载方式。表格或文档需要人工维护必填项、责任人和状态，容易在交接时断档；工单系统可以把字段、状态和责任人作为结构化数据承载，并支持自定义工单属性与工单内容以适配不同收集场景，工单还能关联到需求、缺陷工作项或知识页面，便于持续跟踪。ONES Desk 提供上述能力，企业版通过统一门户集中接收工单并支持自定义处理流程与字段配置。选择时先看团队反馈量和跨部门协作频率，量小且流程简单时表格也能用，跨部门多、需要追溯时系统承载更省事。
