客户打电话来问到底什么时候能修好，工程师说在等配件，仓库说配件在途，采购说供应商还没发货。一圈问下来，三天过去了，设备还停着。月底看报表，平均维修时长九点六天，数字摆在那里，却没人说得清这九点六天花在哪。
一、总时长是个结果，不是原因
只考核总时长，团队只能看到一个笼统的数字，改也不知道从哪改。把它拆开，每一段有自己的责任人和可控手段，问题才会浮出来。分段之后还会发现，拖长总时长的往往不是修得慢，而是等得久。
二、拆成六段，每段都有时间戳
- 报修到接单：客户打电话、发消息到有人受理
- 接单到派工：确定谁去、什么时候去
- 派工到到场：路上时间与预约等待
- 到场到定位：判断故障、确认是否需要备件
- 待件到货：等配件、等调拨、等供应商发货
- 修复到客户确认：修完到客户签字或回访确认
六段在工单里都是状态变更，系统自动记时间，不需要工程师额外填表。状态设计得粗，时间就采不到；状态设计得细，工程师又嫌麻烦。六段是多数设备服务能接受的粒度。
三、四个常见堵点，对应四种改法
- 待件占比高：把常用件前置到服务车或区域仓，按历史故障频次定清单
- 派工慢：给工程师打技能标签，按设备型号匹配，不按谁空闲派给谁
- 到场等待：和客户约固定时间窗，减少到了没人的空跑
- 确认拖：完工当场用手机确认，不等回办公室补单
四、举例说，一组数字把瓶颈找出来
假设某月完成一百二十单，平均总时长九点六天。拆开看：接单零点三天、派工零点七天、到场一点二天、定位与修复二点四天、待件三点六天、客户确认一点四天。加起来正好九点六天，待件一段占了三点六天，接近四成。再看设备型号，待件集中在三类易损件上。把这三类件按每台服务车两套的标准前置，待件段降到一点一天，总时长变成七点一天。一百二十单乘以二点五天，一个月少掉三百天的客户等待。
五、看分位数，不看平均值
平均值会被大量快单拉低，掩盖少数拖了很久的单。按月看第八十百分位与第九十百分位，才知道长尾有多长。超过七天的单子逐单列出来，看卡在哪一段，比看一个平均数字有用得多。
报表还要按三个维度切：按设备型号切，能看出哪类产品故障集中、该改设计还是改培训；按区域切，能看出服务半径是否合理；按工程师切，能看出是技能问题还是排班问题。三个维度交叉，改进动作才有落点，不然一份报表看完只剩一句大家都要努力。
这套分段计时的做法，用 9527CRM 这类轻量级 CRM 的工单状态、自定义字段与报表就能落地：工单按六段设状态，状态变更自动记时间，待件原因做成下拉选项，报表按型号、区域、工程师三种维度出分位数；由于支持私有化部署，设备序列号、故障记录与维修履历都存在企业自己的服务器上，数据随时能完整导出与备份，不被厂商锁定，客户问起数据放在哪里时也答得干脆，管理者要的是可控，不只是一套工具。
