账号健康政策信号看板：通知、时限、证据与根因
把分散在通知、商品、履约、客户和安全模块的信号统一记录严重度、截止、影响范围、证据和负责人。
账号健康很少只表现为一个总分。政策通知、商品抑制、投诉、物流、退款和安全事件往往分散在不同后台模块；如果没有统一责任和截止时间，团队会在限制扩大后才发现同一根因已经重复发生。
看板最小字段
| 字段 | 用途 | 填写规则 |
|---|---|---|
| 官方信号 | 保留平台原名和入口 | 不用内部简称替代原文 |
| 发现时间/时区 | 判断剩余处理窗口 | 同时记录平台与本地时间 |
| 严重度 | 排序销售、资金、权限和安全风险 | 与团队统一定义绑定 |
| 影响范围 | 账号、站点、SKU、订单、仓库 | 不明范围标“待确认” |
| 截止与提前量 | 防止卡在平台最后时限 | 指定负责人和备份人 |
| 证据包 | 支撑调查、申诉和整改 | 原通知、订单、质检、物流、沟通 |
| 根因/重复 | 从个案升级为流程整改 | 关联供应商、SKU、仓库或操作人 |
五类信号分开管理
政策类看规则和申诉；商品类看抑制、下架、知识产权与安全；履约类看取消、迟发、缺货与妥投；客户类看投诉、退款和重复差评；安全类看登录、权限、支付和异常操作。不同类别由不同团队处理，但进入同一看板。
严重度不是凭感觉
可以按四个维度评分：是否影响销售、资金、账号权限或人身/监管安全；影响多大；是否可逆；剩余时间多短。涉及安全、身份、资金或大范围权限的问题应直接升级，不能被其他“低分”平均。
申诉之前先对齐事实
通知、订单、商品页、物流、质检和沟通中的时间、数量与主体必须一致。先写事件时间线，再区分事实、假设和纠正措施。不要复制与本案无关的通用申诉模板。
关闭工单不等于关闭根因
同一 SKU、供应商、仓库或员工重复出现的问题，必须产生流程整改、责任人和复核日期。看板每周输出新增、逾期、重复和高严重度趋势，不只看结案数量。
政策原文先走平台公告核验流程，突发变化按24 小时、7 天与 30 天行动表，物流相关信号接入物流与清关风险看板。
常见问题
总分正常还需要记录单条通知吗？
需要。总分可能滞后或不覆盖全部模块，单条通知的截止和影响范围更适合驱动行动。
平台没有公开阈值怎么设置预警？
以官方可见信号和自己的历史基线设置内部提前量，不虚构“平台红线”；记录规则核验日期并随后台变化调整。
申诉成功后证据可以删除吗？
不建议立即删除。按法律、平台和内部留存要求保存原通知、提交材料和结果，用于重复问题复盘；同时控制访问权限。
服务商代运营时谁负责看通知？
合同中应明确主责、备份、检查频率和升级时限，但账号主体仍需保有控制权和查看权限，不能完全依赖服务商口头提醒。
核验入口
- Temu Seller Center：以当前账号的通知、规则、商品和订单状态为准。
- 欧盟委员会 Safety Gate 与产品安全入口：涉及欧盟产品安全信号时核对主管机构信息。
- 各平台指标和申诉时限必须在对应账号后台、官方政策页和工单中逐项核验。
核验日期：2026-08-16。