Temu账号绩效突然下滑时，最容易做错的不是少看了一个指标，而是把结果指标当成原因：流量少了就改标题，退款多了就降价，履约慢了就催仓库。我的判断是，升级方案应该先把合规要求转成可追踪的日常控制，再讨论投放、选品和转化优化。账号表现不是靠一次“补救动作”稳住的，而是由商品信息、库存、发货、售后和证据留存共同构成的一套运营系统。
卖家常把合规理解成“平台要求什么，我就补什么”。但在实际经营中，商品资料错误可能引发审核、下架或流量中断；库存不准会造成缺货、取消和延迟履约；售后证据散落在聊天记录、仓库表格和邮件里，则会拖慢争议处理。它们看起来属于不同部门，最后却都会落到账号经营结果上。
因此，我会把“合规管理”定义为：在商品上架、库存变更、订单履约、售后响应和资料归档等关键环节，设置责任人、校验条件、异常提醒和可回溯证据。它不是单纯增加审批，而是把高风险错误拦在发生之前，并让已经发生的问题能快速定位、及时纠正。
升级的先后顺序也很重要：先保交易连续性，再保履约稳定，再治理商品与市场规则，最后才扩大增长动作。若账号正处在商品限制、订单取消或争议处理中，先加预算或扩品，可能只是放大尚未解决的风险。
我通常把账号表现拆成三层。结果层包括成交、转化、退款和取消；过程层包括库存准确、按时发货、客服响应和异常处理时长；控制层则看资料是否完整、规则是否复核、变更是否留痕。只盯结果，容易把经营波动误判为流量问题；只盯流程，又可能做了大量记录，却没有减少实际损失。
更有效的诊断方式，是为每个结果指标寻找一个可被团队控制的前置过程。例如，取消率上升后，不能只要求运营“多关注订单”，而要继续追问：取消是否集中在某个仓、某个SKU、某个库存同步时段？库存更新延迟是否超过内部设定的容忍时间？补货责任人是否明确？
| 经营结果 | 优先检查的过程 | 可采取的控制动作 |
|---|---|---|
| 订单取消增加 | 可售库存、同步频率、缺货处理 | 设库存缓冲、标记高风险SKU、规定停售条件 |
| 履约异常增加 | 订单分配、拣货、交接与轨迹回传 | 按仓库和承运环节拆分时长，设置升级提醒 |
| 退款或争议增加 | 商品描述、质量反馈、售后证据 | 按原因归类，抽查页面承诺与实际交付是否一致 |
| 商品审核受阻 | 资质、标签、图片、类目和市场要求 | 建立上架前资料清单，保留版本与审核记录 |
这里的表格不是平台规则清单。平台要求会因站点、类目、销售模式和规则更新而不同，具体事项应回到卖家后台及对应市场的官方要求核验。表格的用途，是让团队知道从哪里开始追查，而不是用一张通用清单代替正式审核。
我在梳理跨境店铺流程时，最常见的一类问题并非某个人故意违规，而是团队规模增长后，原来靠口头提醒维持的流程失效。运营改了商品承诺，仓库仍按旧版包装；采购认为补货已经发出，运营表格却没有更新；客服处理过一次退款，质量团队没有收到具体原因。每个人都完成了自己理解的任务，整个链条却没有闭环。
举一个匿名化的情景推演：某家居用品卖家经营约 120 个SKU，旺季前增加了促销和备货频次。最初的问题只是两个热销SKU库存不足，随后出现订单取消、买家咨询增加和客服处理时间拉长。团队一度把原因归结为“旺季订单波动”，但拆开订单和库存记录后，发现库存表每天只集中更新一次，促销期间的销量变化无法及时反映到可售量。
这个例子中的SKU数量、过程和变化属于情景模拟，不是某个商家的公开经营数据，也不是平台平均表现。它说明的是一种常见的因果结构：局部信息延迟会在订单扩大后放大，随后被误读为履约能力或服务质量问题。没有订单级和SKU级记录，团队就很难区分需求突然增加、同步滞后与补货失误。
第一阶段是信号出现：某个SKU的咨询、退货、延迟或库存差异变多，但单日波动还不明显。第二阶段是问题积累：相同原因在多个订单重复发生，团队开始用临时表格和人工沟通弥补。第三阶段是触发：订单规模、活动节奏或平台审核把积累的问题暴露出来，运营才发现资料、库存、售后和责任人之间没有共同记录。
在管理上，不能把所有异常都设成同一等级。一次偶发的物流轨迹延迟，与同一仓库连续发生的出库超时，不应触发同样的处置。我的做法是同时看频次、影响范围和可逆性：单次且可补救的问题先记录；重复发生或影响多个SKU的问题要升级；涉及安全、知识产权、强制标签或商品真实性等事项，则先暂停相关操作并核验官方要求。
这套分级不是为了给风险贴标签，而是防止团队被大量低影响提醒淹没。若所有异常都被当成紧急事项，真正需要立即止损的问题反而容易被淹没在群消息和待办里。
同一商品在不同市场销售，可能涉及不同的标签、警示语、产品责任、税务或消费者保护要求。即使卖家已有一套资料，也不能推定它在所有市场、所有商品变体和所有时间都适用。尤其是更换供应商、包装、材质、配件或商品宣称后，原先保存的文件可能已经不能准确证明当前在售商品。
我建议把“商品资料”看作带版本的经营资产，而不是一次性上传的附件。至少要能回答：文件对应哪个SKU和版本、由谁审核、覆盖哪个市场、什么时候需要复核、商品实物或包装变动后是否作废。这样做的价值不只是应付审查，也能避免运营团队在不同页面上复制过期信息。
标题、图片和卖点当然影响用户理解，但流量或成交变化并不能自动证明内容是唯一原因。若商品库存不可售、审核状态变化、履约体验下降或活动结束，页面改写不一定能解决问题。更糟的情况是，团队为了“提升转化”加入未经验证的性能宣称，反而带来误导风险。
我的判断顺序是先核对可售状态和商品限制，再看曝光、点击、加购、支付等漏斗变化，然后按SKU、日期、市场和流量来源切分。只有当曝光相对稳定、点击或购买转化出现结构性变化，且没有明显库存与履约异常时，才值得把页面表达作为主要假设来测试。
降价可以改变购买门槛，却不能修复尺寸信息不清、商品与图片不符、包装受损或发货延迟。如果退款原因主要集中在商品预期不一致，继续降价可能增加订单量，同时放大售后成本。判断促销是否有效，至少要把成交额和贡献利润、退款、取消、广告或活动费用放在同一时间窗口观察。
我会把“促销后净结果”拆成成交贡献、售后损失和额外履约成本，而不是只看销售额。若订单增加但每单贡献下滑，且相同原因的退款变多，促销可能是在加速暴露供给问题，而不是推动健康增长。
网盘里有证书、标签照片和供应商文件，不代表这些资料能对应到当前销售的商品。文件若无法关联SKU、批次、市场、有效期限和审核记录，遇到查询时仍需大量人工确认。尤其是商品发生换版或换供应商后，旧资料仍被团队引用，反而会制造“资料看似齐全”的错觉。
我更看重的是证据链是否闭合：资料来自哪里、对应哪个商品、谁核验过、何时更新、发生变更后如何重新审核。资料管理的质量，不在文件数量，而在能否快速证明“这份资料为什么适用于这个商品和这个市场”。
自动同步、批量上架和自动提醒能减少重复劳动，但不会自动判断所有例外。若源数据本身错误，自动化只会更快地扩散错误；若提醒阈值过宽，问题会漏报；阈值过窄，团队又可能被告警疲劳拖垮。先明确数据责任和例外处理，再考虑自动化，通常更稳妥。
对于高风险字段，我倾向于采用“机器校验加人工复核”：系统负责必填项、格式、SKU映射、库存差异和到期提醒；人工负责判断宣称是否有依据、商品变更是否影响资料适用性、异常处置是否符合对应市场要求。两者的边界要写清，不能把最终责任推给工具。
全店平均履约时间可能看起来稳定，但其中某一个仓、某一类商品或某个时段已经明显恶化。全店平均会把局部风险稀释掉。订单量较小时，单个异常也可能让比例大幅波动；订单量较大时，平均值又可能掩盖少数SKU的严重问题。
因此，除了总体数据，我还会看分组数据：按SKU、仓库、市场、承运商、订单日期和异常原因拆分。对样本量很小的分组，不急着下结论，而是同时看绝对件数和比例；对持续出现的高影响问题，则追踪连续周期，不用单日波动代表长期趋势。
面对异常，我不会先问“要不要整改”，而会先问四个更具体的问题：第一，是否涉及消费者安全、商品真实性或法律义务；第二，问题影响多少订单、SKU和市场；第三，现有证据能否证明当前商品和页面信息一致；第四，继续销售是否会扩大损失或让纠正变得更难。
如果涉及潜在安全问题、资料适用性无法确认或商品与宣称明显不一致，我会优先采取保守动作，暂停相关商品或市场的扩张，并尽快根据官方要求核验。若是低影响、可逆且证据完整的运营偏差，可以设定观察窗口和止损阈值，而不是立即对全店做大范围调整。
| 判断维度 | 需要收集的证据 | 更合适的处理方向 |
|---|---|---|
| 风险严重度 | 商品类别、用户影响、适用要求、潜在损失 | 严重风险先限制相关操作并核验要求 |
| 影响范围 | 受影响SKU、订单、仓库、市场与时间段 | 范围明确时定点处理，避免无差别改动 |
| 证据可信度 | 商品实物、页面版本、供应商资料、物流记录 | 证据不足时先补齐事实，不贸然归因 |
| 经营可逆性 | 库存规模、活动状态、改动成本、恢复路径 | 难以逆转的动作需更严格复核 |
一个轻量的风险排序方法，是为每类问题分别评估影响程度、重复概率和发现难度。可以使用1至5级的内部评分，把三项相乘作为相对优先级。它不是科学测量，也不代表平台分数，更不能替代法律或商品安全判断；它的作用是让团队讨论时使用同一套语言。
例如，商品主图版本错误可能影响多个市场，重复概率中等，但在上架前抽检较容易发现；库存同步滞后可能频率较高，影响随促销放大，且订单形成后才暴露。即便两者评分相近，处理动作也不同：前者强调发布前版本校验，后者强调同步频率、安全库存和异常停售条件。
评分后还要加一个“强制升级条件”。涉及法规、安全、知识产权、平台明确要求或疑似数据造假的问题，不能因计算分数低而排在后面。量化方法是帮助排队，不是帮人绕开底线。
每个被确认的问题，都应留下一条可追溯记录：异常是什么、证据在哪里、影响范围是什么、谁负责处理、采取了什么措施、什么时间复核、复核结果如何。若只有“已提醒仓库”“运营已知悉”这样的描述，就无法证明控制动作是否真正改变了结果。
我建议把问题状态控制在少数几种：待核实、处理中、待复核、已关闭、升级处理。每种状态明确进入和退出条件。比如，问题不能仅因有人回复就转成“已关闭”，而应在约定观察期内查看同因异常是否下降，或者抽样确认页面、库存、证据资料已经更新。
结果指标回答“经营发生了什么”，过程指标回答“团队做了什么”，控制质量指标回答“预防机制是否有效”。只设置结果指标，员工可能用短期手段压低数字；只设过程指标，容易出现打勾完成却没有经营改善；控制质量指标则用来检查资料、审核和复核是否真实可用。
启动阶段无需堆很多指标。对多数团队，先选取消或退款类结果、库存或履约类过程、资料和复核类控制指标，各两三项即可。连续运行一段时间后，再根据实际问题调整。不要为了看板好看而追踪团队无法解释、无法采取行动的指标。
下面用一个匿名化的多SKU卖家情景说明如何分析，不把它写成真实客户案例，也不把模拟结果包装成平台数据。假设团队经营约 120 个SKU，销售覆盖两个市场，最近四周发现取消、退款原因和客服工单都在增加。团队已能从订单、库存、物流与售后记录导出基础数据，但不同表格的SKU写法不一致。
第一步不是立刻买系统或重做全部流程，而是先统一最小字段：订单号、SKU、市场、下单时间、仓库、承诺发货时间、实际交接时间、库存记录时间、取消或退款原因、证据链接和责任人。没有统一键值，团队很容易把同一个商品当成不同记录，或者在汇总时把不同变体合并。
以数跨境作为数据整理与分析思路的示例时，我会重点讨论如何把经营数据按商品、订单、仓库和市场建立一致的分析口径，再通过看板或报表定位变化。这里不对其当前功能、连接器、权限或套餐作未经核验的承诺；实际采用前，应根据官网说明和团队需求确认数据来源、更新频率、权限控制、导出能力及费用。
不少团队一开始就想做综合看板，却忽略基础映射。若平台导出的商品编码、仓库系统编码和采购编码不一致，指标即使计算正确，也可能落在错误商品上。我通常会维护一张主数据映射表，记录内部SKU、销售SKU、变体、供应商编码、适用市场和商品版本，并设置变更审批人。
然后用订单号把库存、物流和售后记录关联起来。这样才能判断某类退款是否与具体批次、仓库或页面版本有关。若暂时无法自动关联，先以人工抽样方式核验一批订单，明确错配率和修正成本；当人工整理已经成为稳定、重复的工作，再评估自动化是否值得投入。
假设情景模拟中，某四周取消订单由 30 笔升至 48 笔。仅看数量会觉得问题增加 60%，但若同期订单量也增加，取消率的变化可能小得多。反过来，订单总量减少时，取消笔数看似下降，比例却可能恶化。所以必须同时看取消笔数、取消率和订单基数，并按周或日观察，而不是只对比两个总数。
对退款和争议也一样。先统一原因分类，再看每类原因的件数、占比和对应商品；不要将“质量问题”“与描述不符”“尺码不合”等不同原因全部塞进一个模糊类别。若数据来源对原因定义不同，先保留原始字段，再增加内部映射，不要覆盖原始记录。
| 观察字段 | 情景模拟变化 | 建议追问 |
|---|---|---|
| 每周取消订单数 | 30 笔升至 48 笔 | 订单基数是否变化，增量集中在哪些SKU和仓库？ |
| 库存差异SKU数 | 8 个升至 19 个 | 差异发生在促销时段还是日常同步？ |
| 平均异常处理时长 | 9 小时升至 16 小时 | 是否因责任人不清、证据分散或跨部门等待造成？ |
| 重复售后原因占比 | 22% 升至 31% | 是否集中在同一商品承诺、批次或包装问题？ |
这些数值是便于展示分析过程的情景模拟，不是数跨境的用户数据、行业均值或Temu公开标准。真实诊断时，应使用店铺自己的订单数据，并注明时间窗口、分母口径、剔除规则和异常值处理方式。这样，即便换人维护，也能复现同一结论。
如果库存差异主要集中在少数高销量SKU，我会先对这批商品设置更短的同步周期、人工复核或安全库存；如果异常分散在多个仓库，则要检查系统接口、字段映射和盘点流程；如果退款集中在某个商品描述或包装版本，应该把页面承诺与当前实物、说明书和供应商资料逐项核对。
每次只改变一组主要控制动作，能减少“做了很多事但不知道哪项有效”的情况。比如先改库存更新与停售阈值，观察取消和缺货订单；确认有效后，再处理售后分类或页面内容。若同时调整价格、图片、库存和促销，结果有变化也难以判断因果。
最终看板应服务于三种行动：发现异常、指派责任、复核效果。若一个图表既不能帮助识别变化，也不能触发负责人或复核动作，它可能只是展示装饰。数据工具的价值，不是替团队做判断，而是让判断更快、口径更一致、证据更容易追溯。
稳定阶段不适合一上来就建设复杂审批。先抽取近四到八周的数据，确定订单取消、退款、履约异常、资料缺项和人工处理时长的基线。选出订单量高、退货原因集中或资料变更频繁的商品做试点，并记录当前流程中的交接点。
随后建立最小可行清单：商品上架前由谁核验资料；库存发生变更由谁更新；异常达到什么条件必须升级；售后证据保存在哪里；复核由谁执行。把流程控制在团队能够持续遵守的范围内，优于制作一份没人使用的长清单。
若取消、退款、延迟或审核异常连续几个观察周期恶化，我会先冻结可能放大问题的动作，例如扩大促销、快速增加相似商品或扩大受影响市场。冻结不等于全店停摆，而是把风险范围缩到已确认的问题商品、仓库或流程。
接着按“时间，SKU，仓库，原因，责任环节”切分，抽查订单原始记录，并在短周期内复核。若找到共同原因，立刻建立负责人、临时控制和长期修复三项记录。临时控制解决眼前风险，长期修复则处理数据映射、供应商管理或责任交接等根因。
收到平台或相关方的资料要求时，先确认具体商品、市场、字段、文件格式、提交渠道和时限；再核对当前在售版本与资料版本是否一致。团队不要从旧文件夹里随意挑一份“看起来像”的文件提交，也不要在不确定时用未经核验的陈述解释商品特性。
如果资料缺失或不匹配，记录缺口和补齐责任人，同时评估是否应限制相关商品的销售或扩张。对法律、产品安全和消费者保护要求，应查阅对应市场的官方来源或寻求合格专业意见。内部经验可以帮助提高效率，但不能替代正式的法规判断。
活动前的准备不应只看预计销量，还要核对库存可信度、仓库吞吐、供应商交期、包装和资料版本、售后人力以及数据更新能力。计划销量若超过仓库和客服的稳定处理容量，即使短期成交增长，也可能在履约与售后端形成积压。
我会先做一个压力测试：以近期峰值订单量为基础，模拟订单增长、补货延迟和客服需求同时发生时，哪些环节先达到上限。测试不需要复杂模型，关键是明确最先失守的环节和对应的降载动作，例如收紧促销、调整可售库存或优先处理高风险订单。
多市场经营时，应把商品资料、页面承诺、标签和当地要求按市场维度关联。不能因一个市场已通过某项检查，就假定其他市场的文件、语言或标示要求完全相同。对同一产品的不同变体，也要确认材料和包装是否一致。
如果团队暂时没有能力持续维护多个市场，优先缩小销售范围并确保现有市场资料完整，通常比同时扩张多个市场更稳妥。管理能力不足不是靠更快上架解决的，而是需要在商品数、市场数和运营复杂度之间做取舍。
如果团队连SKU主数据、责任人和状态定义都没有统一，直接引入新工具未必能改善问题。旧表格中的模糊字段会被原样搬进去，最后变成更贵、更复杂的混乱。我的建议是先用两到四周整理关键字段、异常分类和责任边界，再评估数据是否需要自动汇总、提醒或权限管理。
当人工整理开始反复消耗运营时间，且问题确实来自跨系统数据分散、更新不及时或复核遗漏时，才适合评估数据工具。以数跨境作为候选方案示例，团队可以先明确需要汇总哪些来源、需要哪些分析粒度、数据多久更新、谁能查看和导出，再结合其官方当前说明确认能否满足。不要仅凭演示界面判断实际适配性。
工具成本不只是订阅费用，还包括数据接入、字段清洗、权限配置、培训、维护和异常处理。若每月节省的人工时间不足以覆盖这些投入，或者数据质量问题仍需大量手工纠错，工具未必值得立即上线。相反，若错误库存和重复核查持续造成取消、退款或人工加班，改善数据链路可能带来更大的经营价值。
可用一个简化的决策框架：每月可减少的重复工时乘以内部人力成本，加上经验证的损失减少额，再与工具及维护成本对比。由于损失归因常有不确定性，不要把全部成交增长都算成工具贡献；最好先用一个类目或仓库试点，比较上线前后的同口径指标。
| 取舍 | 优点 | 代价与适用条件 |
|---|---|---|
| 先人工治理，再自动化 | 投入小，能快速发现字段和流程问题 | 规模扩大后人工维护成本上升，适合早期或低频异常团队 |
| 先治理高风险SKU | 能把资源集中到订单量大、影响面高的商品 | 低销量但高安全风险商品不能仅因销量低而忽略 |
| 减少市场与商品扩张 | 降低资料、库存和售后复杂度 | 短期增长空间受限，适合控制能力尚未跟上的团队 |
| 加快扩张并同步补流程 | 可能更快获得市场机会 | 对数据、库存和客服能力要求高，必须有明确止损阈值 |
例如，为了降低取消率而把可售库存设得极低，可能减少缺货取消，却同时错失销售；为了压低退款率而拖延受理，也会损害用户体验并带来更大的争议成本。任何指标都有可能被“优化”到失去经营意义。
因此，我会为核心指标配一个护栏指标。降低取消率时，同时看缺货造成的销售损失；缩短客服响应时，同时看一次解决率和重复咨询；提高资料审核速度时，同时抽查资料准确性。只有主指标改善且护栏未恶化，才能判断方案有效。
前两周的目标不是“把所有问题解决”，而是先建立可信的现状。整理订单、库存、履约、售后和商品资料的来源，统一SKU与订单关联键，标记数据更新时间和缺失情况。对销量高、异常集中或资料变动频繁的商品优先抽查，记录实际流程与系统记录之间的差异。
同时确定内部基线。每个指标都要写清楚时间窗口、分子、分母、排除项和来源。例如，取消率按下单订单还是已付款订单计算，退款按发起时间还是完成时间归档，都可能改变结果。定义不一致时，先解决口径，不要把不同报表拼成一条趋势线。
选出最重要的三至五类风险，给每类设定负责人、触发条件、临时动作和复核要求。常见重点包括库存差异、商品资料版本、履约异常、重复售后原因和外部资料到期。不要一次给所有SKU增加同样的流程负担，可以先按风险和订单规模分层。
在这个阶段，团队要把异常从聊天记录迁移到可追踪的工作记录中。记录至少包含问题、影响范围、证据位置、处理人、到期时间和复核结果。若使用共享表格，设置必要的权限和修改记录；若使用专门工具，则检查数据访问范围和导出可用性。
到第七周以后，不要只统计完成了多少任务，而要看重复异常是否下降、处理时长是否缩短、证据是否更容易找回，以及过程改动有没有带来新的副作用。观察周期应覆盖足够的订单量，订单稀少的商品则用抽样核验和历史记录辅助判断，避免因短期随机波动得出过度结论。
有效的控制动作要写进正式流程，并指定维护责任人；无效动作要保留原因，及时调整，而不是因为已经投入时间就继续执行。规则也需要定期回看，尤其是商品版本、市场范围、供应商、仓库和平台要求发生变化时。
这五个问题能把复盘从“汇报数字”变成“确定下一步”。会议结束时，至少要形成一个可执行动作和一个明确复核日期。若问题尚未查清，也要写明当前假设、缺少的证据和下一次判断条件，而不是用“继续关注”结束讨论。
跨境经营中，外部物流、市场需求和平台审核都可能带来不可完全消除的波动。把目标设成“永不发生异常”既不现实，也可能导致层层审批、响应变慢。更合理的目标是：高风险问题能被及时发现；重复问题有明确根因；纠正动作能被复核；团队知道什么情况下必须升级或暂停。
我会把“重复发生率、从发现到接手的时间、证据一次齐备率、复核后再发率”作为管理机制的观察指标。这些数字不能直接替代平台绩效，但可以帮助团队判断内部控制是否在变好。若账号指标波动，而内部控制指标持续改善，就要继续检查外部因素与数据口径，而不是急着否定整个方案。
Temu账号升级不应被简化为一次性整改、重新装修商品页或购买某种工具。更可持续的做法，是把商品承诺、库存、履约、售后和资料管理连接起来，让每个关键变化都有责任人、证据和复核结果。这样，账号绩效不再依赖某位员工记得所有细节，而是由团队能够重复执行的机制支撑。
我最看重的判断标准不是看板有多少图，也不是流程文件有多厚，而是发生一次异常后，团队能不能在合理时间内回答三个问题：影响了什么、为什么发生、怎样证明已经修复。答案越清楚，临时救火和重复犯错就越少。
如果现在就要行动，我建议先挑选一个订单量较高、异常较集中或资料变动频繁的类目，收集近四周数据，统一SKU和订单字段，选三项结果指标、三项过程指标和两项控制指标。随后用两周时间确认问题模式，再选一到两个控制动作进行试点。
试点结束后，把实际节省的时间、异常变化、实施成本和新增负担一起复盘。若结果可信，再扩到更多SKU、仓库或市场；若数据不足，就先修正数据口径；若控制动作增加成本却没有降低风险，也要及时收缩。合规管理不是增长的刹车，而是让增长建立在可验证、可纠正、可持续的经营基础上。
读者评论
文中提到的库存同步延迟和异常接手时长，适合作为内部观察项，但不同店铺订单量、仓库系统差异很大。我会先用一段时间的实际数据校准阈值，直接照搬示意数字可能造成误报。
跨团队交接确实容易断在版本更新上。我们之前也遇到运营改了商品信息、仓库没同步的情况；比起多加审批，我觉得明确变更通知对象和生效时间更实用。
按SKU和仓库拆数据比只看全店平均更容易找到问题。不过样本少时比例很容易失真，最好同时看具体订单数和连续几周的变化，再判断是否需要暂停销售。