上新会带来成就感，状态管理不会。可售、停售、平台下架、授权失败、图片拒登、库存为零却仍在前台显示，这些状态混在同一张商品列表里时，运营看到的是“有一千个链接”，仓库看到的是“不知道哪些还要拣”，客服看到的是“买家问的那款到底还能不能买”。HelloWorld跨境电商助手把多平台商品收进商品中心，价值之一就是让同一内部SKU在各站点的状态能被统一看见、被规则改写、被人工纠偏。下面只写商品运营状态：有哪些状态值得管、怎么批量改、怎么和库存及刊登衔接、怎么避免把不该卖的货留在前台、把不该停的货误伤下架。
先在商品中心认状态，不要只在平台后台凭感觉搜
平台侧的叫法不统一，有的叫在售，有的叫已上架，有的叫Inactive、Banned、Deleted，还有审核中和搜索抑制。中台里至少要能区分六类：在售可买、在售但不可履约、主动停售、平台强制下架或拒登、资料不完整未发布、映射或授权异常导致状态未知。六类处理方式不同，合成“有问题的货”一列，谁也不知道该补图、该补货、该申诉还是该放弃。
内部SKU仍是主键。一个编码下面挂三个站点，可能出现美国站在售、另一站点拒登、第三站点库存为零却仍显示可买。只看主款状态会误判。进入商品中心后按内部SKU展开站点行，看每行的平台状态、中台状态、可售数、最近一次同步时间。同步时间停在很久之前，先当授权或任务失败，不当成“卖得不好”。状态未知的行先修连接，再谈运营决策。
列表筛选要比搜索框常用。筛选在售且可售为零、在售且低于安全库存、停售但仓库仍有货、平台拒登、预检失败未发布、活动结束仍挂着活动价。每天开店先看这几组，比从第一页慢慢往下翻更接近真实工作。数量大时按类目或店铺拆开看，全店一千行一起改状态，手滑的代价是整类目消失。
主动停售和被动下架要分开处理，原因写在系统里，不要写在记忆里
主动停售是你们决定不卖：滞销清仓结束、季节结束、合规风险、要改包装重新拍图、要合并重复链接。被动下架是平台决定不让卖：类目资料缺、图不符、疑似侵权、账号绩效、政策变化。HelloWorld里改中台状态为停售，应同时把原因和预计复查日期写进备注。没有原因的停售，两周后没有人敢重新打开，仓库里的货会变成说不清的积压。
主动停售的标准动作是：中台标停售，库存任务把各平台可售推到零或暂停销售，客服模板改成该编码不再销售并视情况给替代款，广告侧停投。不要只在一个平台后台点下架，另外两个平台还在出单。也不要只改中台标签、不同步到平台，买家仍能下单，仓库会问为什么停售的货还在拣货单里。
被动下架不要用同一套“全平台置零”去报复性处理。一个站点拒登，别的站点仍可能合规在售。先读平台理由，缺图补图，缺属性补主数据，疑似侵权先停该站点并让有权限的人评估，再决定其他站点是否跟停。把拒登原因回写到主数据检查项，同一错误不要在下一批评刊登里再犯。申诉和修改资料属于刊登与合规，不属于仓库点发货能解决的问题。
在售但不可履约，是最容易被当成“还在卖”的危险状态
前台可买、仓库无货、货在途、货在次品仓、授权失效写不出去、低库存规则没生效，都属于这一类。商品中心若只显示“在售”，会给人假象。必须把可售数、占用、在途、次品和同步状态放在同一行看。可售大于零且主库存为零，优先修同步和映射，而不是先去拍新图。主库存有货且前台为零，看是不是活动预热被人手在平台关掉、是不是安全库存把可售吃完、是不是该站点仓没有货却被错误地当成全网可售。
处理顺序固定：先让前台停止继续接不能发的单，再补货或调拨，再打开。打开的条件写在库存规则里，例如可用高于安全库存并且质检完成。运营口头说“货到了可以卖了”，系统里仍是停售或可售为零，客服会按系统回答无货，两套口径会同时出现在会话里。状态以中台加平台前台为准，不以群消息为准。
套装和变体要按子状态管理。主款在售、某尺码永久缺货，应停该变体而不是整条链接。整条停会误伤其他尺码；不停缺货变体，买家会专点那个尺码然后取消。商品中心里变体行要能单独改状态，改完同步到各平台对应子SKU。对照表乱的，先修对照再改状态，否则停错对象。
批量改状态只允许在筛准之后，并且先走小批量
全选后点停售或恢复在售，是商品中心里破坏力接近删除店铺的按钮。批量前用筛选把对象锁死：同一原因、同一类目、同一站点、同一仓库状态。原因不同的货不要进同一批。先导出或在界面确认行数和抽样标题，再执行。执行后抽查前台，确认停的是那些链接，恢复的是那些链接。
恢复在售比停售更危险。停售错了，少卖；恢复错了，超卖、违规页重新露脸、旧活动价复活。恢复前检查主数据是否仍完整、图片是否仍符合当前规则、价格是否仍是有效公式、库存是否真的可履约、拒登原因是否已消失。任何一项不确定，保持停售。季节款重新上架按新刊登预检走一遍，不要假设去年能过的页今年仍能过。
测试店和主力店的状态不要批量联动。测试店可以随意停、随意恢复，用来练手。主力店的批量恢复只给审核角色。子账号权限在这里再次发挥作用：编辑可以建议停售，审核才能把恢复推到平台。
状态要和刊登队列、库存任务、客服话术三处对齐，只改一处等于没改
商品中心标停售，刊登队列里若仍有该SKU的改价改图任务在等待发布，任务会把停售页重新激活或改出一套新的可买页。停售时同步取消或暂停该编码的待发布任务。库存任务若仍按旧规则把可售推回去，前台会在几分钟后复活。停售原因是合规，库存任务必须加入黑名单或排除规则，不能只靠当天手改一次数字。
客服侧把停售编码加入不可售回复，并视情况给替代编码。买家拿着旧链接进来，坐席如果还按在售去答应预留，仓库没有货，纠纷从状态不一致里长出来。广告侧停投与状态同步，停售链接继续烧点击，是在为不能履约的页付钱。
平台强制删除或链接合并后，中台映射要改，不要长期留着“在售”空壳。空壳会污染销售排行和库存周转，数据上看起来像滞销，实际上是尸链接。定期用平台状态回写清洗：平台已删的，中台标归档，不再进入补货和广告池。归档不是删除主数据，成本、图片和对照表还在，以后重新刊登用同一内部SKU，避免再造一个编码。
日常巡检用固定几组列表，比每隔几天“整理一下商品”有用
每天看：在售且可售为零、同步失败、平台拒登新增。每周看：停售但仓库可用仍高、在售但长期无单且占用仓位、重复映射。每月看：归档清单是否还在广告或促销里、季节款恢复计划、类目政策变化后哪些在售页要预检。巡检结果只允许变成三种动作之一：修资料后保持在售、停售并写原因、归档。讨论很久却不改状态，列表会越来越长，最后没人打开商品中心。
状态管理不产生上新数量，却决定仓库拣的是不是该拣的货，客服答的是不是还能买，广告花的是不是还能发的链接。HelloWorld把各平台商品放进同一张桌子上，桌子有用的前提是每一行都有一个被承认的状态，并且这个状态能写到前台去。会改状态的团队，链接可以很多；不会改状态的团队，链接越多，越不知道自己在卖什么。