制造业官网补案例时，售后记录常只留在客服系统里，页面编辑拿到的只有一句“问题已处理”。客户关心的产品ID、工况、检测记录和处理结果没有对应关系，案例复盘就会变成空话。判断方向不是把售后故事写得更长，而是把可公开的证据字段提前整理出来。
客服记录要先和产品资料对齐
售后系统里的记录适合跟进问题，却不一定适合直接写进官网。常见情况是客服单只保存客户名称、联系人、故障描述和处理状态，产品页需要的型号、批次、安装环境、配件版本却散在报价单、发货单和产品手册里。编辑要复盘案例，先要把这些字段连成一条线：产品ID对应哪一版手册，型号简称是否和官网页面一致，客户反馈里的“卡滞”“漏液”“噪声”分别对应哪类工况，处理方案是否有检测记录支撑。没有这一步，案例页很容易把售后沟通写成泛泛的服务态度，客户看完仍不知道这个问题是否和自己的场景有关。
资料对齐还要处理公开边界。售后单里可能有客户名称、现场照片、订单金额和内部责任判断，这些内容不适合原样进入页面。更稳妥的做法，是建立一张案例证据表，把可公开字段和内部字段拆开。可公开部分保留产品类别、应用环境、问题现象、处理方式和复检结果，内部部分保存工单号、客服负责人、报价版本和原始附件位置。凯乐丰在官网规划和内容管控中，会把这类字段放到案例素材表，而不是让编辑从聊天记录里临时摘句子。
如果案例涉及检测报告，还要把报告编号和图片修订记录放在同一行。比如售后复检照片已经裁掉客户场地，但原图文件名仍能暴露项目编号，页面图片就不能只看缩略图是否好看。可以参考检测记录和工况对应关系的处理方式，把检测日期、样品编号、判定结果和公开说明分开保存。这样改写案例时，编辑知道哪些内容能写，哪些内容只能作为内部核对依据。若资料来自不同部门，还要记录领取时间和确认人，避免同一张照片被两个案例重复引用，也方便后期撤换。
复盘流程要留下交接痕迹
售后记录进入案例库前，至少要经过销售、技术和内容负责人核对。销售确认询盘来源和客户原始需求，技术确认问题机制和处理边界，内容负责人确认页面能不能公开。每次核对都要留下状态，而不是在群里回一句“可以”。状态字段可以很简单：待补产品ID、待核检测报告、已确认公开范围、已发布到案例页。后续有人更新同一案例时，就能看到卡在哪个环节，不会把旧图纸、旧报价或未确认的处理结果重新放上去。
官网案例还要和询盘交接相连。客户看完案例后提交表单，销售不能只收到“来自案例页”四个字，还应看到案例ID、产品页面、语言版本和客户选择的咨询类型。这个逻辑可以借鉴询盘来源字段设计，把案例浏览记录和表单记录关联起来。售后案例的价值不在于讲一个完整故事，而在于让客户提出问题时，销售能迅速判断他关心的是同类工况、同类型号，还是只在找参考图片。CRM中保留这些字段，也能减少二次询问客户的次数。
AI参与整理售后素材时，字段审核要更严格。模型可以帮助把客服对话归纳成问题现象和处理过程，但不能自动补客户行业、测试结论或项目效果。发布前应按字段白名单检查：是否保留产品ID，是否引用检测记录，是否说明公开边界，是否删除客户名称和报价信息。若案例材料还需要改写，可对照AI改写案例素材的证据保留，把工单号、附件编号和审核状态留在后台，不让它们混进公开正文。这样，售后记录才能成为可核对的案例资产，而不是一段看起来完整、实际无法追溯的描述。
