一、先看痛点：售后坏在"单子说不清"，不是坏在人不努力
售后这件事，问题很少出在一线的人身上，多半出在信息上：
- 报修入口散：电话、微信、业务员转述、客户直接找工程师，最后只有接电话那个人的本子上有一条记录。
- 派单靠记忆：主管凭印象分单，谁熟悉哪家客户、谁手上有几单，全在脑子里；人一休假，单子就压住。
- 完工没凭证：工程师回来了，做了什么、换了什么件，靠口头说；月底对不上配件消耗。
- 回访没人管：修完就结束，客户满意不满意无从得知，同样的故障反复出现也没人发现。
- 超时没人看：等客户催第二遍，才知道第一遍的单子还没派出去。
这些现象背后是同一个缺口：每一次报修，没有一个从产生到关闭都在系统里的记录。工单模块要解决的，就是让每一张单子有明确的当前状态、明确的责任人、明确的时间点。
二、数据怎么建：一张主表 + 两张从表 + 几本基础档案
搭模块的第一步是定数据结构。售后工单的骨架不复杂，关键是字段和状态要想全。
1. 主表：工单
一张工单一行，建议包含这些字段：
- 工单号（自动编号，客户和工程师对账都用它）
- 客户与联系人（引用客户档案，不重复录入）
- 联系电话、服务地址
- 服务对象（设备或产品，可选绑定设备档案）
- 报修来源（电话 / 微信 / 现场 / 客户转述，用字典统一）
- 故障描述、紧急程度（普通 / 加急 / 紧急）
- 报修时间、期望上门时间
- 当前状态、当前负责人（工程师）
- 派单时间、上门时间、完工时间
- 处理结果摘要、费用相关字段（按需）
- 附件（现场照片、客户确认照片）
其中"引用客户档案"指的是：平台有一套引用引擎，可以让一个模块的下拉选项直接取另一个模块的数据（也就是软外键），不用把客户名称再抄一遍，也就不会出现"同一个客户三种写法"。
"用字典统一"指的是平台内置的数据字典：像报修来源、故障类别这类只有固定几个选项的字段，集中放在字典里维护，改了字典所有页面同步生效，不用逐个页面去改。
2. 状态流转：每个状态都要有出口
建议设计成这样一条链：
待派单 → 已派单 → 处理中 → 待回访 → 已关闭
另外准备两个旁路状态：
挂起（等客户确认时间、等配件到货）退回 / 重派（工程师到不了、判断不属保修范围等）
设计状态时自查两条：每个状态都要说清下一步由谁在什么条件下推动；不能有"卡死"的状态——比如"挂起"必须留一条回到"待派单"或"处理中"的路。
3. 从表：处理记录（一次上门或一次沟通一行）
工单是一次报修的"事"，处理记录是这件事里的"过程"。字段建议：
- 处理时间、处理人
- 处理方式（上门 / 远程 / 电话指导，用字典）
- 故障原因、处理动作、处理结果
- 本次耗时
- 附件（过程照片）
这样一张工单下面能看到完整时间线。客户再来问"上次到底修了什么"，翻详情页就有，不靠回忆。
4. 从表：配件消耗
- 配件（引用配件或物料档案）
- 数量
- 用途说明（哪张工单、哪一步用的）
- 是否收费 / 是否走保修（用字典）
配件单独成表的好处是：月底想统计"这个月哪种件用得最多、哪些工单超出了保修范围"，有数据可算。
5. 基础档案与服务规则
- 客户档案：名称、联系人、地址、服务等级——与销售侧共用一份数据，不让多渠道各存一套
- 工程师档案：姓名、联系方式、技能类别、负责区域、在职状态
- 设备 / 产品档案（可选）：序列号、安装日期、保修到期日
- 字典：故障类别、处理方式、报修来源
- 服务时限规则：按紧急程度约定响应时限与上门时限。服务时限约定（业内叫 SLA）的意思是：客户报修后多久必须有人应答、多久必须上门，超过就算超时。具体时限由企业自己定，系统只负责存规则、算超时。## 三、页面怎么用：四个视图就能跑起来
数据结构定好之后，页面围绕"谁在什么时候需要看什么"来组织。
1. 工单列表：让"该我管的单子"一眼可见
- 默认视图：我的待处理 / 今日需上门 / 超时未响应
- 筛选条件：状态、报修来源、客户、负责工程师、报修时间段
- 列表上直接标出"超时"和"挂起天数"
- 支持批量派单与导出
2. 派单页：从"凭印象"到"看得到负荷"
派单时要把候选工程师的关键信息摆在一起：负责区域、技能类别、手上未完工的单数。指派完成后，工单状态自动推进到"已派单"，同时给工程师发出一条通知（站内信，需要时走短信通道）。
改派和退单都要留痕。留痕靠平台的操作审计日志——谁在什么时候改了哪张单，事后能查出来。
3. 工单详情页：一页看完一件事
建议的版式是上下结构：
- 工单基本信息
- 处理记录时间线（按时间倒序）
- 配件消耗明细
- 附件与照片
完工提交时要做必填校验：故障原因、处理结果、照片缺一项就交不了。这一步是把"质量要求"变成"系统约束"——约定写在制度里会走形，写在表单校验里不会。
4. 统计看板
- 工单量趋势、按来源和故障类别的分布
- 平均响应时长、平均完工时长、超时工单占比
- 工程师工作量与一次解决率
- 回访满意度分布
看板的价值不在好看，而在于每周例会能回答两个问题：上周哪类故障在变多？哪个环节在堵？
四、流程与自动化怎么接：该提醒的交给系统
- 报修登记 → 自动生成工单：状态置"待派单"，进入派单池
- 派单 → 自动通知：通知工程师，主管视图同步标记"已响应"
- 超时 → 自动升级：用平台的定时任务（按设定周期自动执行的动作）扫描未响应、未上门的工单，超时即提醒主管或升级处理
- 完工 → 自动生成回访任务：到期提醒客服跟进，回访完成再把工单置为"已关闭"
- 需要审批的场景：费用减免、超出保修范围的配件更换、上门延期说明，都走工作流（可视化配置的审批流）：谁审、几级审、什么条件下加签，在流程定义里配，不写死在代码里
- 数据触发规则：例如"紧急程度 = 紧急"时自动置顶并通知主管，可以用平台的数据流规则来配
一句话概括这段的设计原则：凡是"人容易忘"的环节，都做成系统到点自己触发。
五、移动端怎么配合：工程师和主管都在手机上
售后是典型的"人不在电脑前"的业务，PC 端是管理侧，真正的操作在手机侧：
- 工程师：看我的工单 → 接单 / 开始 → 上传现场照片 → 登记处理结果与配件消耗 → 完工提交。PC 上建好的模块会自动同步到手机端，不用为手机再开发一套。
- 主管：手机上看待派单池和超时提醒，随时指派或改派。
- 接单员：客户报修进来时，按统一的报修表单代录（而不是录音式口述），客户、设备信息由档案带出，字段和必填项都固定下来，源头就规整。
移动端上线前重点测两件事：现场网络差时能不能提交成功（照片大、信号弱是常态）；字段与 PC 端是否完全一致（两边不一致，统计口径就散了）。## 六、上线前查什么：六项自查
- 字典口径：故障类别、处理方式、报修来源是否只有一份定义，历史数据能不能对上
- 状态闭环：每个状态的出口都写清了？有没有只能进不能出的单
- 权限与可见范围：工程师只看自己的单、客服看全量、主管能改派——角色和数据可见范围一起定
- 必填校验：完工提交的校验项是否与质量要求一致，照片是否必填
- 通知通道：站内信、短信、邮件通道是否配好并能送达
- 预检与发布：模块发布前走一遍平台的预检（发布前的自检，把字段、页面、权限的问题提前挑出来），确认菜单挂载和移动端同步正常；发布出问题有错误账本可查，能回滚
存量工单要不要迁移、迁多少，建议先定口径。平台的 Excel 建模块能力可以先把表格变成模块结构，字段对齐后再把历史数据带进来——不建议为了"数据完整"把几年的乱账全搬进新系统。
七、之后怎么延伸
- 设备档案绑定：工单挂到设备上，"这台机器修过几次、是不是老毛病"一眼可见，保修期内外的判定也有依据
- 备件库存联动：配件消耗与备品备件库存打通，领用即扣减，避免"账上有、仓里没有"
- 年度维保计划：用定时任务按合同周期自动生成计划工单，从"坏了才修"走向"按计划保养"
- 服务费用与结算：工单上的费用字段与应收应付关联，服务收入不再单独记一本账
- 知识沉淀：故障原因加处理方式积累到一定量，就是一份可检索的维修知识库，新工程师上手更快
售后工单是那种"看起来只是记几条数据、实际决定客户续不续约"的模块。它的价值不在功能多，而在于每一张单子从产生到关闭都有迹可循。这也正是 AI 构建器适合切入的地方：数据结构、管理页面、移动端伴同、到点提醒与审批流转，按业务语言描述清楚就能先搭出来跑起来，再根据实际使用中暴露的问题迭代——先有闭环，再谈精细。