Temu半托管店铺最常见的优化误区，不是不会调价格或不会做活动，而是运营已经把商品推起来，仓库却不知道该备多少货；仓库发现缺货，运营仍在按旧库存接单；财务月底才发现，销售额增长并没有带来利润增长。要回答“temu怎么优化”，我更愿意先看团队协同：半托管把更多履约责任留给商家，商品、库存、订单、物流和利润因此成了一条互相牵连的链路，任何一个环节的信息延迟，都可能把流量变成缺货、延期或亏损。
我判断一个半托管团队是否进入可优化状态，不先看它有多少运营人员，也不先看报表做得多漂亮，而是检查四个接口有没有对齐：运营与供应链之间的需求接口、库存与订单之间的履约接口、物流与平台时效要求之间的交付接口、财务与商品决策之间的利润接口。
如果运营只看到曝光、点击和订单，供应链只看到采购单，仓库只看到待发货列表，财务只在月末核算毛利，那么团队不是在共同经营同一家店，而是在分别完成几份互不相连的工作。半托管场景下，这种割裂尤其容易产生隐性成本：多备货会增加资金占用，少备货会造成断货，仓库错过出库窗口可能影响履约表现，折扣没有纳入完整成本则可能把亏损误判成增长。
我的核心建议是先建立“商品计划，可售库存，订单履约，结算利润，复盘调整”的闭环，再优化单个岗位的操作速度。有了闭环，团队才能判断某个商品应不应该加库存、某次促销应不应该参与、某个物流方案是否值得换，而不是凭感觉做局部决定。
这个闭环不要求一开始就采购复杂系统。团队小的时候，一张字段明确、责任人明确、更新频率明确的协同表也能工作。关键是每个数字要有口径，每个异常要有负责人，每个决策要能追溯到当时看到的信息。
第一类是库存口径。仓库实物、可售数量、待质检数量、已分配订单数量、在途数量不能混成一个“库存”字段。第二类是时效口径。团队必须说清楚订单从什么时候开始计时、仓库几点截单、异常何时升级，以及谁负责向运营反馈。第三类是利润口径。至少要明确销售收入、采购成本、平台相关费用、物流和包装费用、退货损耗及促销让利是否纳入。
不同站点、类目和时期的具体规则可能变化，履约时限、费用项目、可用功能都要以卖家后台和当前政策为准。协同表的价值不是替代规则核验，而是把团队已经确认的规则转化为每日动作。
我不会只用“员工觉得沟通更顺”来判定协同改善。至少要观察三组结果：库存信息延迟是否缩短，订单从进入待处理到交接承运的时间是否稳定，商品经营结果是否能解释清楚。若三项都没有变化，通常说明团队只是增加了会议或表格，没有改变信息传递和决策流程。
对小团队而言，第一阶段不必追求所有指标都实时化。先把断货、超时、错发、成本漏算这几类高损失异常变得可见，往往比追踪几十个漂亮指标更有用。
半托管的关键特点，是商家与平台承担的工作边界和全托管不同。商家通常需要承担更多商品经营、备货或履约相关工作，平台侧负责哪些环节，则要结合所在站点、商品类型和当前规则确认。实际经营中，团队不能简单套用“平台会处理”的旧认知，也不能把半托管理解成只换一个销售入口。
最容易出问题的地方，是岗位之间默认对方已经知道变化。运营认为仓库能看见活动排期，仓库认为库存数字由运营确认，采购认为销量预测已考虑在途货，财务则认为商品成本表足够完整。每个岗位的假设单独看似合理，叠在一起就可能造成备货错误。
举个常见的情境：某款商品平时日均出单较低，运营计划参加促销；供应链按历史均值备货，仓库没有收到活动时间和预估增量；活动开始后订单超过原先计划，团队才发现补货周期长于剩余可售天数。问题不是某个人“没有努力”，而是活动计划没有转化成库存动作，且没有明确谁确认风险。
有些团队看到销量上涨，就把它理解为“赶快多备货”。但库存决策至少要同时看需求速度、补货周期、可售库存和需求波动。若补货需要较长时间，临时加单未必能赶上销售窗口；若商品季节性强，过量备货又会造成滞销和资金沉淀。
一个简化的协同判断可以是：预计覆盖天数等于可售库存除以近期日均销量。这个计算只能用于初筛，不能替代对活动、周末、物流波动和销量趋势的判断。若日均销量取的是很短周期，促销峰值会把覆盖天数压得过低；若取很长周期，近期增长又可能被平均掉。
因此我更倾向于在表格里同时呈现“基准需求”和“情景需求”。基准需求用来维持正常经营，情景需求用来评估活动或流量上升时的压力。团队至少应该知道：销量比预期高多少会触发补货讨论，低多少会暂停追加采购。
很多人把效率理解为减少沟通次数，甚至认为流程越少越好。我认为更有效的定义是：正常订单不被多余审批拖慢，异常订单能够快速找到责任人和处理动作。没有异常分级的团队，往往会让所有问题都挤进群聊；有了明确规则后，团队才能把日常处理标准化，把注意力留给真正需要判断的事件。
例如，库存少于补货周期需求时，应该通知运营、供应链和采购；仓库拣货数量与系统数量不一致时，应先冻结相关库存并核对；承运交接延迟时，仓库应报告预计完成时间，由运营判断是否需要调整销售预期或执行其他措施。每种异常都要有时限，而不是等某位负责人空下来再处理。
销量上涨只是结果的一部分，不能单独证明经营更健康。若新增订单依赖大幅折扣、加急运输、额外包装或高成本补货，毛利可能下降；如果促销带来的订单超出仓库处理能力，履约风险也会升高。运营看成交额，财务看最终利润，仓库看处理负荷，三者之间必须通过同一商品计划连接起来。
我建议在活动审批前，先写下目标指标和止损条件。比如活动目标不只写销售额，还要列出最低毛利要求、库存上限、预计订单量、仓库日处理能力和超出预期后的处置方案。数字可以是团队自己的计划值，但必须有负责人确认，不应以事后解释代替事前判断。
仓库里有货，不等于这些货都能立即用于销售。部分库存可能待质检、已被订单占用、包装不符合要求、批次信息不完整，或者还未完成系统登记。若运营只按仓库实物数设置销售计划，就会产生“账面有货、订单却发不出去”的错觉。
我会把库存至少拆成四种状态：可立即销售、已分配待发、待检或待处理、在途未入库。每种状态的更新责任不同。仓库负责实物和异常状态，运营负责销售计划，采购或供应链负责在途节点，负责人每天检查差异，而不是要求所有人反复问“现在到底还有多少”。
更重要的是，库存数字必须带时间戳。上午更新的库存，到了下午可能已经不适用。若订单增长快或仓库频繁处理库存，团队应增加更新频率；若商品稳定、订单少，则可以采用固定时段核对。更新频率不应统一照抄，而应按库存变化速度设定。
群聊适合提醒，不适合承载唯一的经营记录。消息会被新内容覆盖，后加入的同事找不到决策过程，口头确认也很难追踪。会议同样如此：如果没有固定输入、决策结果、责任人和截止时间，会议只是把不同岗位的焦虑集中表达一次。
我会把会议压缩成“异常、决策、责任、期限”四项。例会只讨论需要跨部门决策的事项，其余日常状态放在共享看板或表格中。每个动作都要有负责人，不能写成“运营跟进”“仓库注意”这种没有具体责任主体的描述。
系统可以减少重复录入、集中数据和提醒异常，但它不能替团队回答“什么算可售库存”“谁有权调整销售计划”“超时由谁升级”。流程没想清楚就上工具，常见结果是把原本散落在多个表格里的混乱搬到一个界面里，甚至增加双重录入。
我建议先用一到两周做流程盘点，找出哪些动作重复、哪些数据经常冲突、哪些异常没人负责，再决定是否需要软件。工具采购前要验证三个问题：能否连接团队现有数据，能否支持必要的权限和提醒，能否让负责人看到经营异常而不必逐行查表。采购与接入成本也要纳入评估。
订单及时发出，并不代表商品经营有效。若成本表没有更新，团队可能不知道物流方案变更、包装调整、采购价格波动或退款损耗对利润的影响。尤其当活动促销和补货同时发生时，销售增长容易掩盖单位经济模型变差。
利润核算不一定要一开始做到复杂，但至少应建立商品级的成本清单，并标记每项数据的来源与更新时间。尚未确定的成本可以单独列为估算项，不要把估值混进已核实成本。决策者应知道自己看到的是“已结算结果”还是“经营预测”。
团队初期最值得跟踪的，不是几十个运营数据，而是能够提前提示风险的领先指标。库存覆盖天数可以提示断货风险；订单按时交接率可以提示履约能力；库存差异率可以提示账实准确性；活动前备货确认率可以提示计划是否真正落地。结果指标仍然重要，但它们通常在问题发生后才显现。
指标数量应服从决策需要。每个指标都要能回答一个实际问题：谁看、什么时候看、超过什么条件要采取什么动作。如果团队无法说清楚某个指标改变后会做什么，它很可能只是报表装饰。
建议先选三到五个核心指标，在一个商品组或一个仓库试运行两周。确认数据能稳定获取、阈值有人负责后，再逐步扩展。不要一开始就要求运营、采购、仓库、客服和财务各自提交几十项指标，最后把大量时间花在填报上。
“库存覆盖天数由供应链负责”还不够。真正可执行的定义应包括：数据由谁更新，运营何时核对，低于多少天触发补货评估，补货需要几天，若来不及是否需要调整活动计划。指标只有和具体动作绑定，才成为管理工具。
我常用一张异常决策表，把触发条件、首要处理人、协同人员、处理时限和最终决策人写清楚。处理人负责收集事实，协同人员提供专业判断，决策人对资源取舍负责。这样可以避免一个问题在多个群里转发，却没有人做最终决定。
| 异常类型 | 触发信号 | 第一责任人 | 需要协同的岗位 | 建议动作 |
|---|---|---|---|---|
| 库存覆盖不足 | 预计可售天数低于补货周期加安全缓冲 | 供应链负责人 | 运营、采购、仓库 | 核实在途与需求情景，再决定追加采购或调整销售计划 |
| 账实差异 | 系统可售量与实物盘点不一致 | 仓库负责人 | 运营、数据维护人员 | 先冻结受影响数量，查明差异原因后再恢复销售计划 |
| 交接延误 | 订单接近内部截单时间仍未完成交接 | 仓库负责人 | 运营、物流对接人员 | 确认可完成时间及订单范围，及时调整后续处理安排 |
| 促销毛利偏低 | 促销测算低于团队设定的最低利润要求 | 运营负责人 | 财务、采购、供应链 | 复核折扣、成本、履约费用和备货规模，再决定是否参与 |
单独使用过去七天平均销量做补货判断，可能把短期促销、节假日或断货造成的低销量当成常态。更稳妥的做法是并看短周期趋势、较长周期基准和已知活动计划，并标注数据是否受到缺货影响。缺货期间的销量不是完整需求，直接拿来预测容易低估真实需求。
阈值也不应只由负责人拍脑袋。可以先依据补货周期、仓库处理能力和历史波动设一个临时建议值，再在每周复盘中核对触发次数与实际结果。若告警太频繁、团队长期忽略，说明阈值太敏感；如果总在问题发生后才报警，则说明阈值或数据更新频率过于滞后。
日常节奏解决“今天会不会出问题”。建议用短时间核对待处理订单、库存异常、缺货预警、交接延迟和当天活动变化，异常只讨论事实和动作，不做长篇经营分析。
每周节奏解决“下周的资源是否匹配”。运营提出销售与活动计划，供应链说明供货能力，仓库说明处理容量，财务提供成本变化。周会要产出一份已确认计划和一份风险清单，不能只留会议纪要。
月度节奏解决“哪些假设错了”。复核商品毛利、库存周转、促销效果、退货或异常成本、预测偏差。每次复盘只选几个影响最大的偏差，写清楚是数据问题、流程问题、判断问题还是外部变化，并决定下个月是否调整规则。
下面的案例是我用来说明协同方法的情景推演，不是数跨境客户案例，也不是该平台的实际经营数据。数值用于展示团队应该怎样记录、比较和复盘，不能被引用成行业平均水平。不同店铺的类目、供应周期、仓库能力和站点规则不同，指标基准必须由自己的历史数据验证。
假设一个经营家居小件的团队有二十多个在售商品，运营两人、供应链一人、仓库由外部服务方处理，财务每月集中核算一次。团队的主要问题是活动排期没有稳定传递到备货环节，库存表中还把现货和在途货放在同一列，促销后才发现部分商品的履约成本高于预估。
我不会先要求这个团队换系统，而是让他们先把商品计划、库存状态和订单异常统一到一份可追溯的工作底表中。底表先管理最关键的字段：商品编码、计划售价、活动日期、基准销量、活动情景销量、可售库存、已分配数量、在途数量、预计到货时间、仓库处理能力、单位成本、异常负责人和最后更新时间。
试点时先挑十个代表性商品：包括销量稳定商品、近期增长商品、长补货周期商品和利润偏薄商品。运营每周提交需求情景，供应链核对可供数量与到货时间，仓库确认库存状态及处理容量，财务核对成本口径。每项数据都标记来源，未经确认的预测值使用“估算”标识，避免团队把预测误当成事实。
日常中最重要的变化，不是表格更完整，而是商品计划开始带着问题进入协同。例如，运营提出活动销量预估后，供应链不再只回复“有货”，而是分别说明现货、已占用和在途数量；仓库也不只回复“能发”，而是确认活动峰值下每天可处理的订单范围；财务则标记哪些成本已经核实、哪些仍是暂估。
在两周试点里，团队可以记录库存差异率、活动前备货确认率、订单交接时长、预测偏差和成本数据完整率。下面的变化是为了演示该如何设定试点观察口径，属于情景模拟数据，不是对任何工具或商家的效果承诺。
| 观察指标 | 试点前示意值 | 试点后示意值 | 解读重点 |
|---|---|---|---|
| 库存差异率 | 12% | 5% | 看库存状态拆分和更新时间是否改善账实一致性 |
| 活动前备货确认率 | 55% | 90% | 看销售计划是否真正获得供应链和仓库确认 |
| 异常首次响应时间 | 约 10 小时 | 约 3 小时 | 看异常责任人和升级路径是否清楚 |
| 成本字段完整率 | 70% | 92% | 看商品决策是否拥有更完整的利润输入 |
这类示意数据只能说明“应当测什么”，不能证明“换了流程一定提升多少”。试点结束后，还要排除订单量变化、促销季节性、仓库人员调整等影响。若响应时间变快但差异率没有改善，可能只是沟通更及时，库存源头仍不可靠；若备货确认率提高但滞销库存上升，则应检查预测偏差和采购决策。
以数跨境为例，我会把它放在“跨境经营数据如何集中查看和用于决策”的评估环节，而不是把它当成协同流程本身。团队可以访问其官网了解当前产品介绍、适用范围和功能说明，再结合自己的业务逐项核对：是否支持所需数据来源，指标口径能否解释，商品或订单维度是否适配团队工作流，数据更新频率是否满足决策时点，权限和导出方式是否符合内部管理要求。
官网地址：https://shukuajing.jiushuyun.jiushuyun.com。具体产品能力、接入渠道、报价、数据延迟和可用功能可能随版本或服务范围变化，落地前应以官网当前介绍及实际演示确认。本文不据此推定任何特定功能已经适用于所有半托管场景。
我在做工具评估时，会带一份真实问题清单去看演示，而不是只看首页上的功能名称。例如：能否把团队需要的销售和商品信息放在同一分析路径中；导出的数字是否能追溯到来源；当数据与仓库实物不一致时，系统能否帮助定位问题，还是仍需人工盘点；团队能否把工具中的洞察转化成补货、定价或促销动作。
如果工具只展示结果，却无法解释口径，团队仍然需要额外建立数据字典。如果工具能汇总部分经营数据，但仓库、采购或物流信息不在其中，也不能默认它已经形成端到端协同。选型时要把“数据看板”“流程管理”“订单履约”“利润核算”拆开评估，不要因为一个平台覆盖其中一项，就把它当成全部经营系统。
若试用结果证明工具能减少重复整理、提升数据可见性，再评估团队投入的订阅费、实施时间、培训成本和维护责任。工具的价值应该用节省的人时、减少的错误和改善的决策质量来衡量，而不是用页面数量或功能数量来衡量。
小团队通常不缺沟通渠道，缺的是统一记录和明确边界。建议用一个共享表格维护商品计划、库存状态、订单异常和成本更新时间，字段不要贪多。每个商品只要能快速回答“现在能卖多少、补货要多久、促销是否有利润、谁负责下一步”，就已经比散落在个人聊天记录里的信息强。
每天固定两次检查关键异常即可，时间点按仓库处理节奏设置。运营负责更新活动与需求假设，供应链负责更新可供量和到货时间，仓库负责更新实物与处理状态，经营负责人负责最终的资金和风险取舍。如果一个人承担多个岗位，也要在记录中区分“我以哪个角色确认了什么”，避免职责混在一起。
小团队不一定需要立即上系统。优先改善的顺序通常是统一商品编码、库存状态拆分、异常责任到人、成本字段补齐。若表格已经频繁出现覆盖、漏改或版本冲突，再评估协作工具或系统化管理。
团队扩大后，信息容易在运营小组、采购、仓库和财务之间断开。此时应把交接流程写成明确节点：活动计划何时冻结，采购何时确认，仓库何时回报库存，订单异常多长时间升级，结算数据何时进入复盘。每个节点都要有输入格式和输出结果。
这个规模适合设置每周跨岗位计划会，但会议不要成为所有业务信息的唯一入口。会前由各岗位更新看板，会中只讨论偏差、风险和需要决策的事项，会后把决定写进商品计划并通知相关执行者。重复发生的异常要形成规则，不要每次都靠负责人临场救火。
团队可以设置一个流程负责人，但不应让他替所有岗位做专业判断。流程负责人负责提醒、追踪和记录；运营负责需求判断，供应链负责供货评估，仓库负责履约执行，财务负责成本核验，负责人负责资源配置。
业务复杂度上升后，最大风险常常不是某个订单延误，而是同一个商品在不同表格里使用不同名称、不同库存单位或不同成本口径。团队应先确定商品编码、仓库编码、库存状态、订单状态和费用分类等主数据规则，再谈跨部门看板。
多仓场景下，库存不应只呈现总量，还要呈现所在仓库、调拨时间、适用销售范围和是否被锁定。多站点场景下，规则和时效可能不同，应避免把一个站点的经验直接复制给另一个站点。多类目团队则需根据商品价值、补货周期和波动性设置不同的监控阈值。
如果管理层只要求“全公司一张表”，却不允许保留仓库、站点和商品组的差异字段，统一视图反而会掩盖局部风险。正确做法是统一定义，再保留必要的业务维度。
外包仓的协同难点在于商家不一定能直接控制人员安排和现场优先级。团队不能只用“请尽快发货”作为要求，而要明确订单数据何时交付、库存状态多久反馈一次、异常如何提交、盘点差异如何确认、双方如何界定完成时间。具体服务承诺应以双方合同和实际约定为准。
建议把关键交接拆成可验证事件，例如订单接收、库存确认、拣货完成、复核完成、承运交接。每个节点记录时间和异常原因。发生延误时，先核实订单范围和预计完成时间，再决定是否调整经营计划。没有记录的“已经通知”很难帮助双方复盘。
如果外部服务方暂时无法提供细粒度数据，商家至少应要求固定频率的库存核对和异常汇总，并保留抽样复核机制。合作关系越外部化，信息透明度越重要。
扩量能带来更多销售机会，但备货越积极，资金占用和滞销风险越高。补货周期短、需求相对稳定、库存可转卖性较强的商品，可以考虑提高响应速度；补货周期长、需求波动大或季节性明显的商品，更需要分批采购和设置风险缓冲。
我会要求团队把备货建议拆成基准量和增量量。基准量依据正常需求和补货周期，增量量依据活动或增长情景。增量采购应说明触发条件、资金占用和未达预期后的处理计划。不要因为“活动可能爆单”就把最乐观的预测直接变成采购量。
加急处理、额外班次或更快的运输方案可能降低部分时效风险，但会增加成本。是否值得，需要结合订单规模、商品毛利、当前履约压力和平台适用规则判断。团队要对比“延误可能损失”和“加速确定成本”，而不是把加急默认成越多越好。
对利润较薄的商品，频繁使用高成本加速方案可能使订单越多、亏损越大。对高毛利或短窗口商品，适度增加履约投入可能有合理性。决策时应把方案写清楚，并设定复核期限，避免一次紧急处理变成长期成本。
自动化适合重复、规则清楚、错误容易检测的动作，例如定时汇总、字段提醒和异常筛选。涉及商品是否继续备货、促销是否值得参加、供应风险是否可接受的判断，仍需要理解业务上下文的人作出决策。
团队不应追求“所有动作都自动化”，而要找出人工重复劳动最重、又最不需要主观判断的环节。自动化上线前要设抽检、异常回退和权限控制，避免错误数据被快速扩散。对于成本高、影响大的决策，保留人工复核通常更稳妥。
指标越细，理论上越容易定位问题，但维护成本也会上升。数据来源不稳定、岗位没有时间更新、指标定义反复变化时，复杂看板会很快失去可信度。宁可维护五个口径稳定、能驱动行动的指标，也不要维护几十个没人解释的数字。
每月可以做一次指标清理：没有使用记录的指标先暂停；长期没有可靠数据来源的指标标注限制；重复表达同一问题的指标合并；新增指标必须写明它要帮助哪个决策。这样既能保持视野，也能避免团队把精力消耗在填报上。
流程完全统一，容易让特殊商品被错误处理；每个商品都单独设计，又会让团队无法维护。比较稳妥的做法是统一基本规则，同时为高波动、高价值、长补货周期或特殊履约要求的商品设置例外标签。
例外必须有明确条件和复核时间。若一个商品长期处于例外状态，团队应判断它究竟确实特殊，还是基础流程设计不合理。例外太多时，流程已经失去统一的价值；例外太少时，标准流程可能正在掩盖真实差异。
第一周不急着改所有流程，先把团队现有表格、群聊、系统字段和常见异常列出来。抽取一批真实订单，沿着计划、库存、处理、交接和成本记录向前追溯，找出最常见的断点。每个问题要标记发生频次、影响范围、发现方式和当前处理人。
这一周的产出应是一张问题清单和一份最小字段表。字段越少越好，但商品编码、库存状态、更新时间、异常责任人和下一步动作不能缺。未核实的数据要明确标注，不能用推测填补空白。
第二周选取有代表性的商品，不要只挑最容易管理的商品。至少覆盖稳定销量、增长趋势、补货周期较长和利润敏感等情形。开始执行固定的日检查和周计划会，记录异常从出现到关闭的全过程。
试运行期间不要一边改字段、一边频繁改变口径。若必须调整，要记录调整日期和原因。否则团队无法判断结果变化究竟来自流程改善，还是数据定义改变。
当团队已经知道哪些动作重复、哪些数据需要汇总、哪些异常要提醒，再评估是否需要数据平台、协作工具或系统集成。工具演示时用真实业务问题验证，要求查看数据来源、口径说明、更新时间、权限设置和导出能力。
预算测算不只包括软件费用，还应计算数据整理、接口维护、员工培训和流程迁移的时间成本。若团队规模小、业务变化快，先采用轻量协作方式可能更合适；若数据量大、重复录入多、错误造成的损失明显，再考虑投入更完整的系统。
第四周重点看三件事：异常是否更早被发现，是否有人按期限处理，决策结果有没有影响备货、活动或成本控制。不要只看表格是否填满，也不要把所有变化都归功于新流程。同期订单规模、促销安排和供应情况都可能影响结果。
试点有效，就把已验证的节点推广到更多商品；试点无效，就回到问题链路检查是数据不可靠、责任不清、阈值不合适，还是团队没有执行权限。推广前先修正最关键的断点，不要把一套尚未验证的流程批量复制。
第一，运营提出的销售计划，供应链和仓库是否明确确认过？如果没有，预测就还不是可执行计划。第二，团队能否在一天内判断某个商品的可售库存、在途数量和异常责任人？如果不能，库存协同仍有信息盲区。第三，促销或补货决策能否看到相对完整的成本，并追溯到数据来源？如果不能，销量增长可能掩盖利润风险。
我对半托管优化的判断始终是：先让信息在岗位之间正确流动，再让流程更快，最后才是用工具扩大效率。增长不是把更多订单推给仓库，自动化也不是把错误数据处理得更快。真正值得优化的，是团队能否在正确的时间，依据可信的信息，作出彼此一致的经营动作。
下一步可以从十个商品、两周试点开始：拆清库存状态，固定活动与备货确认节点，给异常安排责任人和处理时限，再用数据核对试点结果。等团队能够解释库存、履约和利润之间的关系，再扩展商品范围或评估系统。半托管店铺的竞争力，不只在于谁拿到更多订单，更在于谁能把订单稳定地履约，并且知道每一单为什么值得做。
读者评论
库存覆盖天数这个指标确实好理解，但促销期间日销量波动很大，最好同时看补货周期和已分配库存，不然单看平均值容易误判。
我们团队以前也把群消息当作库存记录，后来发现交接班后经常对不上。加更新时间和具体责任人后改善不少，不过前提是有人持续维护。
利润复盘值得提前做，但退款损耗和物流附加费用有时要到结算后才完整。预测数据和已结算数据分开标注，会更方便判断活动到底有没有赚到钱。