一、项目背景

我们服务的客户是某区域汽车经销商集团，旗下数十家 4S 店分布在多个城市。这个项目启动前，集团的售后业务基本处于"数据黑箱"状态：每一家店的售后工单、配件库存、客户回访记录都散落在各自的 Excel 表格和一套运行了十多年的老旧 DMS 里。集团层面拿不到统一看板，哪家店工单积压、哪家店配件长期呆滞、哪些客户到了保养周期却没回店，全靠人工月底汇总，而且数据口径对不齐，区域之间还不能横向比较。

更棘手的是客户流失没有预警机制。一辆车完成首保后，如果二保、三保没有按时回店，集团侧完全无感知，等到客户已经去了别家店，再想挽回为时已晚。我们当时面对的核心诉求很明确：先把集团—门店两级售后业务"连起来、看得清"，再谈智能化和精细化运营。我们采用的是 XpShop 的 S2B2C 供应链平台能力（多级组织树与统一商品主数据底座），把它作为集团 DMS 中台的统一数据基础，集团做汇总与管控，门店做本地作业与执行，组织树天然承载了数据隔离与向上汇聚的关系。

二、落地场景

在这个项目里，我们把落地场景拆成四条主线。第一条是集团统一 DMS 中台，所有门店的售后工单不再落本地库，而是统一写入集团中台，按"集团—区域—门店"三级组织树做数据隔离与汇总。第二条是售后工单在线流转，从接车、派工、诊断、维修、质检到交车，全程状态可见，厂长在移动端就能看到本店实时工单池和每个技师的当前负荷。第三条是配件共享库存，集团建立统一配件主数据，各店库存互通，紧缺配件可发起调拨申请，避免各家店重复囤货。第四条是客户全生命周期与保养提醒，系统按车型、里程、上次保养时间自动计算下次保养窗口，提前推送保养召回任务给客服。技师和厂长通过移动作业端接单、扫码领料、上传维修照片，现场作业不再回办公室录系统，工单状态随作业实时推进。

三、关键技术挑战与解决思路

挑战一：多门店售后工单统一流转与 SLA 管控。 老系统里工单状态由各店自定义，集团无法统一定义"超时"标准，看板上红黄绿全靠各店自觉填报。我们用一套集中式状态机统一了工单生命周期，并区分了"计时态"与"挂起态"——比如待料状态不计入 SLA 计时，否则会被供应链到货延迟误判为门店超时。SLA 阈值按业务类型分层：常规保养、事故车维修、索赔工单分别设置不同的 repair_window，超过阈值自动升级到厂长与集团看板。这里踩过一个坑：最初我们把"待料"也算进 SLA 计时，结果每次供应商到货延迟都会让门店 SLA 集体爆红，厂长怨声载道，后来引入挂起态、把待料时长单独计入供应链考核，门店侧指标才回归正常。

挑战二：集团—门店配件共享库存与调拨。 各店此前库存相互独立，主数据编码不统一，同一个滤芯在不同店有不同料号，集团根本无法做总量视图。我们先做了配件主数据清洗，以 OE 号（原厂件号）为唯一键重建统一商品主数据，再在门店库存之上叠加一层"可用库存视图"，实时聚合各店现货与在途。调拨申请触发时，系统按"最近仓优先 + 库存可用量"做智能推荐，并对推荐出的库存量做调拨锁定，避免并发超卖。架构上我们让库存视图走只读副本，写入仍归属各店本地事务，通过事件最终一致同步，降低跨店强事务耦合带来的锁竞争。

挑战三：客户全生命周期与保养召回。 召回触发的难点在于数据口径：里程来自保养记录估算，保养周期来自车型保养手册，二者不一致时容易误召回或漏召回，外呼打错了还会惹恼客户。我们建立了一套规则引擎，以"时间窗口 + 里程窗口"双维度判定，并对置信度低的记录打标走人工复核，而不是直接外呼。召回任务通过工单形式派给客服，可追踪触达率与回店转化，形成运营闭环。这部分我们借用了我们采用的 AI 私有化部署底座中的 RAG 知识库层能力，把各车型的保养手册、技术通报结构化入库，召回规则可引用知识库条目，总部统一维护一次、各店即时生效。

挑战四：旧 DMS 数据迁移与双轨运行。 老 DMS 数据脏乱，工单历史存在大量状态跳跃（如从"已创建"直接跳到"已关闭"），直接导入会污染实时看板。我们设计了增量双轨方案：新中台上线后，老系统继续接单两周，通过 CDC（变更数据捕获）把增量同步过来做对账，差异超过阈值自动告警。历史数据做一次性 ETL，状态不连续的工单统一归并到"历史归档"分区，不参与实时 SLA 计算，避免污染集团看板。双轨期我们每天跑一致性校验脚本，确认无误后才正式切流，全程可回退。

四、效果数据

以下为脱敏示意数据，仅反映趋势量级，非审计级数字：

案例片段（已脱敏）： 售后工单状态机与 SLA 配置（节选）： states: [created, assigned, diagnosing, repairing, qc, waiting_part, delivered, closed] transition: assigned -> diagnosing 需技师扫码上岗，否则 SLA 持续计时 sla.repair_window: 常规保养 4h / 事故车 24h / 索赔 48h sla.waiting_part: 进入 waiting_part 即挂起计时，part_waiting_caps=48h 超时升级集团 escalation: repair_window 超时 -> notify(厂长) + push(集团看板)

五、可复用经验总结

第一，售后数字化一定要先统一工单、再谈智能化。我们当时花了近一半工期在工单状态机与 SLA 标准对齐上，看似慢，但这是后面所有看板和预警成立的地基。如果工单口径都不统一，上再多的 AI 模型也只是把混乱放大，集团看板上的数字谁都不信。

第二，配件共享库存优于各店囤货。这个项目里最大的库存收益不是来自预测补货模型，而是来自"把各店已有库存盘活"——统一主数据 + 可用库存视图 + 调拨锁定量，三步就让集团总库存水位下降，周转天数明显缩短，且门店缺件时的等待时间也变短了。

第三，数据迁移别追求一步到位，双轨 + CDC 增量对账更稳。老系统脏数据不可怕，可怕的是切流后发现对不上又回不去。留两周双轨窗口，用脚本兜底，比一次性大切换安全得多，也给了业务侧适应新系统的缓冲。

第四，客户运营要闭环。保养提醒不是发条短信就结束，必须回到工单、回到回店转化，才能知道召回规则到底有没有用，进而迭代阈值与触达时机。没有闭环的运营动作，长期看都是成本而非收益。