一、先说痛点：投诉来了，谁在跟、跟到哪一步了
几乎每家制造企业都遇到过这样的场景：客户一个电话打到销售，销售转给车间，车间再问品质部，三天过去客户还没等到回音；月底开品质例会，想统计"这个月客诉几起、哪类问题最多、平均几天关单"，只能靠几个人回忆加翻微信记录。
问题不在人不上心，而在于投诉从来没有被当成一条有状态、有责任人、有时间节点的业务记录。它会带来几个连锁反应：
- 没登记：投诉内容留在电话里、微信群里、某张便签上，客户一催就只能挨个打电话问进展。
- 没分类：每条投诉的"问题类型"由不同人随手写，统计时口径对不上，看不出真正的高发问题。
- 没闭环：措施做了，但"有没有效"没人验证；两个月后同一个问题再犯，换个人接手就彻底断线。
- 没时限：没人规定几小时响应、几天关闭，超期只能等客户发脾气。
所以这类模块要解决的其实是一件事：把投诉变成一张从受理、分类、分派、处理、验证到关闭都能查、都能追的单据。下面按"数据怎么建 →页面怎么用 → 流程提醒怎么接 → 移动端怎么配合 → 上线前查什么"的顺序讲。
二、数据怎么建：四类数据撑起一条闭环
先不要想着一次建全，先把主干四块搭起来。
1. 投诉单（主数据）
一条投诉一行记录，核心字段建议包含：
- 投诉编号、投诉日期、来源渠道（电话／微信／邮件／上门／售后回访）
- 客户名称、联系人、联系方式
- 关联批次号或订单号、产品／物料、数量、金额影响
- 问题分类、严重等级、责任部门、期望完成日期、当前状态
其中"客户""批次"如果系统里已有档案，用引用字段把投诉单挂上去（平台提供跨模块的引用能力，写法上就是一个软外键），这样后面按客户、按批次汇总时不需要重复录入，也不会因为手工打字出现"同一个客户两个名字"。
2. 问题分类字典（口径统一的关键）
这一步最容易被忽略，却决定了统计能不能看。把分类做成平台里的数据字典统一维护：一级是质量问题／交付延迟／包装破损／数量短缺／服务响应，二级是具体原因（如尺寸超差、外观划伤、混料、标签错误）。字典集中管理后，页面上的下拉选项全都取同一份，谁录入都是同一个值，报表才合得起来。3. 处理过程子表
一条投诉挂多条处理记录：处理时间、处理人、措施内容、附件。这是保留"过程证据"的地方——客户问进度时，不是靠人回忆，而是打开单据就能看到过程。
4. 整改与验证记录
根本原因、整改措施、责任人、计划完成时间、验证方式、验证人、验证结论（有效／无效／需再整改）。这一块决定"问题会不会再犯"，也是品质例会最有价值的材料。
四块之间用主表—子表的关系连起来，一条投诉从生出到关闭就是一条完整的链路。
三、页面怎么用：五类页面覆盖全流程
数据建好以后，日常用起来主要靠五个页面。
投诉登记页（客服／前台用）
要求是"快"。必填项控制在客户、问题分类、问题描述三个，其余字段允许后补；描述可以直接拍照或上传附件（图片、检验报告、聊天记录截图）。登记完自动进入"待受理"。
我的待办视图（处理人用）
按"我负责／我参与"过滤，只显示和自己相关的单子；超过期望完成日期的行标红，一眼看出哪几单在拖。
投诉处理页（责任部门用）
从受理到关闭的每一步都在这一页推进：接收分派 → 填写原因分析 → 提交整改措施 → 等待验证 → 关闭。每次状态变化留下时间和操作人，谁在什么时候做了什么，事后可查。
管理看板（品质部／管理层用）
按时间、问题分类、责任部门三个维度统计投诉量与平均处理时长；再单独做一个超期清单页，只列未关闭且已超期的单子，例会直接投屏用。
投诉台账列表（全员可查范围）
像查账一样按客户、批次、状态、日期过滤，支持导出，方便对账和留档。
顺带说一个"把判定规则搬进系统"的做法：严重等级不靠人判断，可以设成规则——比如分类落在"涉及人身安全"或"批量性缺陷"时自动置为最高级并由系统直接通知到品质负责人。平台里这类"满足条件就自动处理"的能力（数据流规则与工作流节点）不用写代码，配置即可。## 四、把流程与提醒接上
页面能存能查只是第一步，真正让闭环跑起来的是三样东西：流转规则、提醒、权限。
状态流转用工作流。 受理 → 分派 → 处理 → 验证 → 关闭，每一步由工作流驱动：分派节点指定责任部门（也可以按问题分类自动定到默认部门），验证不通过时自动退回整改环节，关闭必须由指定角色确认。这样"谁来推下一步"不再依赖口头通知。
超期提醒用定时任务。 平台自带定时任务能力，可以配置成每天固定时间扫描未关闭且超过期望完成日期的投诉，给责任人和上级各发一条提醒；每周生成一份客诉汇总推给管理层。提醒的送达渠道可用站内信与邮件，配置在任务里。
权限按角色分。 客服能登记和查看自己录的单；责任部门只处理分派到本部门的；品质部和管理层看全部与统计。权限沿用平台的角色与权限体系配置，不用为这个模块单独造一套。
再往前一步：把客诉接到上下游。 因来料问题导致的客诉，可以关联到供应商档案，形成索赔或质量扣款的依据；产品端的重复问题，可以推到不合格品处置流程里走评审。这些延伸不是第一天就要做的，但数据结构上留好关联字段，后面加法很容易。
五、移动端怎么配合
投诉处理大量发生在车间和客户现场，手机端比电脑端更常用。做法上，PC 上构建好的模块会在移动端工作台里出现，页面按手机屏幕自动适配，不需要再做一套。典型用法：
- 现场上报：车间巡检、驻场工程师发现异常，直接手机登记投诉／异常单，拍照上传，比回来再补记录及时得多。
- 随手处理：处理人收到提醒后点开就能填处理记录、上传照片，不用回工位开电脑。
- 管理层速览：手机上看本周新增、未关闭数、超期数三个数的概况，够用了再打开明细。
六、上线前查什么
模块搭完别急着全员铺开，按下面几条过一遍再发布（平台的发布预检会把明显问题拦在前面）：
- 字段是否齐：编号、状态、责任部门、期望完成日期、分类，缺任何一个闭环都立不住。
- 口径是否统一：分类和原因是否做成了字典，有没有还允许自由填写的地方。
- 权限对不对：拿三个不同角色的账号各登录一次，看能不能看到不该看的单据。
- 流程是否跑通：手工走一条完整链路（登记→分派→处理→验证不通过→再处理→关闭），确认每个节点都能推进、退回正常。
- 提醒是否触达：把定时任务的执行时间临时调近，确认提醒真的发出、对象正确。
- 历史数据怎么进：过去一年的客诉如果想一起进来，用 Excel 导入的方式把表格导成模块数据，比逐条录入现实得多。
- 先小范围试点：挑一个车间或一条产品线跑两周，把字段和时限调顺了再推广——这一步最省事，也最容易被人跳过。## 七、之后怎么延伸
一条闭环跑顺之后，这个模块会长出几个自然的延伸方向：
- 质量成本统计：把返工工时、退换货运费、赔偿金额按投诉单归集，年底能算清楚质量问题到底花了多少钱。
- 满意度回访：关闭后自动生成回访任务，把客户对处理结果的评价写回单据，形成客户档案的一部分。
- 与检验、追溯打通：同一批次既出现在来料／成品检验记录里，又出现在客诉单里，两边互相点得进去，找原因的时间会明显缩短。
- 供应商质量台账：按供应商汇总客诉笔数与类型，作为评级和准入的输入。
八、落地建议
这类模块最容易失败的两种做法，一是一开始就想做全（分类做了三层、报表做了十几张，结果没人愿意录），二是只做记录不做时限（单据都在系统里，但没人对超期负责）。
比较稳的路径是分三步走：
- 第一步只做三件事：投诉能登记、能分派到人、能查当前进度。两周内上线。
- 第二步加时限与提醒：定响应与关闭时限，配上超期提醒和周报。
- 第三步加分析与延伸：分类统计、质量成本、供应商与批次关联。
整个过程不需要开发团队介入。用 Inkwell AI 构建器，把上面这些需求用业务语言说清楚（要管哪些数据、每张页面给谁用、什么条件下要提醒谁），构建器会生成数据表、页面与流程配置，改起来也是说一句改一句——今天先上登记与分派，明天补一个超期看板，都不必推倒重来。