外观
微信扫码加入WorkBuddy交流群
跨境电商库存补货与广告联动
打通各平台库存与业务数据，AI识图回填物流进展并计算补货，库存不足时联动调低广告，减少人工搬运与无效消耗。
能力亮点： 库存广告联动
行业： 电商与零售 适合参考的团队： 跨境电商团队、服装类目卖家、库存与广告运营人员
一个十几人的跨境电商团队，主营东南亚市场的服装生意。服装每个颜色、每个尺码都是独立SKU，每季度新增500到800个，全年大概2500到3000个。库存数据困在多平台聚合SaaS里，新品开发信息又在飞书里，两边互不打通。
原来的业务问题
工具不算少：Excel、聚合SaaS、飞书都在转，最累的是在各个工具之间来回搬数据的人。补货流程长这样——从聚合SaaS里把数据扒下来，填进自己的计算表，按自家的公式算出该补什么颜色、什么尺码、补多少，再把结果誊进另一个模板，最后生成PDF发给供应商，一套下来至少2到3个小时。
物流环节同样原始：工厂发货没有扫码枪，靠拍照、识图，再由员工一张张人工看照片、填写物流单号和进展，每天要花4到5个小时。数据已经产生了，人还在充当"数据搬运工"。
更扎心的是广告：每天在Google、TikTok等平台投放，广告持续烧钱。某个SKU库存已经很低，广告还在跑，客户继续下单，企业却发不出货，广告费还在消耗。SKU从几十几百涨到几千，人一天的时间大量耗在"看、抄、填、核对"上。
项目怎样推进
实施团队没有把"打通两个平台"当成一个API集成项目，而是连开几次会让客户录屏演示实际工作方式，一周三四轮沟通后才看清：库存只是整条链路的一个环节。第一个硬骨头就出现在数据打通上——对方SaaS的API开放程度很低，Key有失效机制且不能多团队共用，一个团队刷新Key，另一个团队的就失效。最后加了一层开源云端数据库Supabase做中转，数据先进中间库，再同步到飞书，让团队在熟悉的业务环境里看到实时库存。
数据通了，最明显的人工瓶颈冒了出来：物流照片。让Agent做"识图+回填"，AI打头阵做第一轮识别和录入，人只做最后检查——AI放在这里，是因为这段工作本来就适合它。补货则完全保留客户原来的公式，由Agent照着算，筛出待补SKU、给出预计补货周期和数量；人工的角色从"计算员"变成"审核员"，确认后直接生成PDF订单发给供应商。
做到这里，客户自然长出了下一层需求：既然知道库存了，能不能让库存反过来影响广告？于是把库存、订单和广告投放情况结合——某个SKU库存降到一定程度，Agent判断对应广告是否还该继续投，先调低额度甚至暂停，避免一边烧广告一边发不出货。整个过程一步步往前推：打通数据，看见新问题，解决新问题，再产生新的业务可能性。规则极死、完全确定的任务则交给脚本定时任务，不为了追热点硬上Agent。
工具与系统
案例提及：飞书。这些名称包含既有业务系统及技术选型，具体角色以案例叙述为准。
做成了什么
效果最直观地落在时间上：物流照片处理从每天4到5小时压缩到1小时以内，人只做最后核对；补货从每次至少2到3小时，变成Agent算出结果后"看一眼、验证一下"就能生成订单。更值得说的是三个结构性变化：从"人工搬数据"变成"数据自动流动"；从"人工计算"变成"AI计算、人工确认"；从"库存、补货、广告各自决策"变成"库存开始影响广告决策"。第三点比省几个小时更重要——以前库存是一个结果、广告是另一个动作，两边割裂；现在业务从单点自动化走向了流程之间的联动。
| 指标 | 项目结果 |
|---|---|
| 物流照片处理 | 由每天4～5小时压缩至1小时以内 |
| 补货计算耗时 | 由每次2～3小时缩短为确认验证 |
披露范围： 按项目披露的试点与实施进展整理。结果由项目方在该项目范围内披露；不代表其他企业采用相同方法即可达到同样效果。
对同类企业的启发
跨境电商团队年SKU数千个，库存数据困在聚合平台，新品信息又在办公工具中，两边互不打通。员工人工看物流照片回填数据，靠表格来回搬数计算补货，库存不足时广告仍在投放，一边烧钱一边发不出货。
补货确认与广告调整保留人工最终判断；平台接口开放程度与密钥共享机制存在限制，需评估中转方案可行性；简单确定任务优先用脚本处理。
如评估同类项目，可以先核对：
- 照片识别与补货结果经人工核对确认
- 广告调整动作可追溯库存触发原因
- 数据同步链路保持原始来源可查
以上为同类业务的实施建议，需结合实际数据、系统条件和产品授权验证。