服饰是电商里售后请求很密集的类目：发货前反悔要取消，收到后尺码不合适要换，颜色不喜欢要退。单看每一件都不复杂，叠起来却吃掉客服大半工时。这篇按一家典型服饰店铺的日常来复盘：售后请求怎么从几个后台收拢到一处。
这类店铺的日常
先看一个具体画像：天猫旗舰店加天猫专卖店加抖音小店，客服两名。一个人偏接待，一个人偏售后和发货，旺季两个人互相补位。店里 SKU 更新快，每季换一批主推，尺码与面料是咨询里的常客。
平时，售后请求分散在三套后台里：买家在哪个平台下单，请求就落在哪个后台，攒一批再集中处理。大促之后情况更明显，未发货退款、七天无理由、少件补发在一两天里同时涌进来，接待不得不暂停，先清售后。
这类店铺不是没有处理标准。什么情况直接退、什么情况要买家先拍凭证，店里其实有共识；只是这份共识没有写成任何人照着都能执行的规则，处理快慢全看当天谁来值班。
除了大促，还有两个集中期：上新两周后，尺码不合适与颜色偏差的退换会一起抬头；清仓与直播专场的价保咨询也不少。这些节奏其实可以预判，提前把规则和排班准备好，比事后加班清积压强。
卡在哪几件事上
- 三个后台各看各的：同一个买家的退款在抖音、补发在天猫，核对要来回切换，谁处理到哪一步没有统一视图。
- 固定动作占掉大半时间：未发货退款、七天无理由这类判断条件固定，却每单都要人工点开、核对、点同意。
- 工单没有统一计时：退款单卡在收尾环节，超过平台时限才被发现，补救起来更被动。
- 风险靠经验识别：高频退货、金额异常、索赔话术相似的买家，只有做得久的客服能看出苗头。
怎么用零九AI 处理
先说收拢。淘宝、天猫、抖店等平台的售后请求进入同一个工作台，未处理与临近超时的排在前面，不用逐个后台翻。多平台聚合接待和售后共用同一个账号，白天接待、晚间清售后都是同一套界面。
再说规则。用「订单状态 + 金额区间 + 买家历史 + 商品类目」组合出判断条件：未发货退款直接同意，七天无理由按买家退货率区间放行，少件补发要求先上传凭证。命中即执行，处理结果自动回填平台后台，不用两边各操作一次。这套机制在售后管理系统里按店铺单独配置，新店或新类目可以先只判断不执行。
同一买家的退款、补发、发票请求自动合并成一张工单，按时间线呈现，客服换人接手时不用重读上下文。高频退货、金额异常、索赔话术相似、集中差评这些信号由系统持续扫描，高危请求不自动执行，只提示、等人工复核。
授权与历史导入的具体步骤，教程里写得比较细：先授权店铺，再做一次历史售后导入，系统就会给出规则建议，细节见帮助中心。
落地过程
接入的顺序建议从小到大。授权需要处理售后的店铺约 3 分钟，只读权限也能先用；导入近 90 天的历史售后约 10 分钟，系统会按记录统计出高频场景与金额分布，给出规则建议；之后规则先只判断不执行，试运行建议 3–7 天，把「系统会怎么处理」与「人工实际怎么处理」放在一起对比；确认一致后，再逐条打开执行权限，高危场景保持人工确认。
改善的方向
改善不是某个数字的跳变，而是几个结构性变化：客服的时间从「每单都要点」转向「只看例外和需要沟通的部分」；积压从「事后发现」变成「临近超时就提醒」；规则命中记录留档，阈值可以按季度调整，处理口径越来越稳定；新店开张时，已经在跑的规则可以按类目复制过去，不用从零配一遍。排班上也一样，售后集中期不再需要全部人手扑上去，接待与售后可以按当天的情况分配。
适合什么样的店铺
- 天猫、抖音等多平台开店，售后请求每天几十件以上。
- 客服两三人，没有专人盯售后，大促后容易积压。
- 退款、退货流程相对固定，愿意先把几个高频场景写成规则。