分开记录上市、库存与接单
登记商品是否已上市、所选 SKU 是否有库存,以及店铺是否接单,这是三个独立字段。同一个页面上,售空颜色和现货颜色可以有不同状态,不能因为另一个颜色能购买就把全商品写成现货。状态来源应具体到负责人员及记录时间。
向经营负责人取得批准的履约预期,并确认从哪个事件开始计算。供应商说“快了”不足以写具体补货日;资料缺失时把文案标为等待确认,先补事实再做紧迫感宣传。不能靠 AI 从主图、新包装或订单按钮推断上市状态。
把状态变成买家能理解的期待
写清现在能做什么、什么仍待完成。未来发售应说明哪些发售信息已确认;等待补货应明确具体款式与批准的等待预期。不要为了标题简短而随意互换标签,也不要用“预售”遮掩真实库存情况。文字需让买家知道等待对象,不仅仅显得专业。
若维护 Merchant Center feed,由负责人直接核对当前字段定义与有关要求。feed、可见页和结账说明应指向相同销售对象。Itemlume 可以基于确认事实辅助写稿,却不修改库存或同步 feed;其他平台也需核对自己的规则,不从 Google 定义外推。
- 记录所选 SKU 的上市及库存状态。
- 确认能否接单以及真实接单条件。
- 取得批准发货预期,不猜日期。
- 比对标题、商品页、结账及有关 feed。
- 状态或承诺不一致时暂停素材发布。
虚构练习:发售与补货两种等待
这是虚构练习:一款尚未发售的新本子,与一款已上市但蓝色缺货的本子,都允许下单。两者状态不同,不能只从按钮得出同样文案。这里不代表某商家真实库存,也不提供保证发货安排;练习意在先确认状态再组织措辞。
团队分别取得负责人批准状态,然后写不同说明。蓝本子补货时间未确认,就不补一个日期,也不引用新本子的发售日。停止条件是销售记录之间一致,而不是图上放了时髦的预售角标。仍有矛盾时保留待确认状态,不让生成的承诺先于运营事实。
发布时再次核对状态
将状态时间和负责人员附在批准稿,图片生成后库存与计划仍可能变化。人工发布静态标题前再查所选 SKU,特别是画面已经包含日期或状态角标时。旧图不随库存自动更新,文字确认与实际投放检查必须有各自记录。 发布记录必须指明所选变体及当时状态;商品系列层面的库存标签,不能覆盖买家实际选择项不同的等待条件。审阅者保留选项值,让后续变化可追溯。
停止条件是买家所见与实际销售记录一致,或者撤下无支持素材。状态指南不是交付保证;feed 接受、生成文案或通用商品记录,都不能证明每个变体采用相同履约期待。把未确认项留下,不用更好听的标签替代缺失事实。
销售状态决策记录
| 观察到的情况 | 人工核对 | 停止或批准条件 |
|---|---|---|
| 未上市 | 确认发售资料 | 使用批准未来发售信息 |
| 已上市无库存 | 确认补货预期 | 说明对应 SKU 等待 |
| 其他颜色现货 | 核对所选 SKU | 不泛化库存 |
| 日期未确认 | 询问经营负责人 | 暂停带日期素材 |
把这张核对表作为人工检查记录,填入自己的真实证据;表中条件不是已经完成的实测结果。
来源与延伸阅读
来源于 核对。平台规则可能变化,发布前请复核原始资料。提示词与工作流程建议是 Itemlume 编辑指导,不是独立测量的结果。
常见问题
能下单就是现货吗?
不是,应分别查看真实 SKU 库存和履约资料。
AI 能选发货日期吗?
不能,需要经营负责人确认,否则保持未确认。
Google 字段定义适用所有店吗?
不是,它限定对应 feed,其他目的端单独核对。
从真实商品开始
用自己的真实商品练习这套方法。
先查看相关工具。AI 文案与创意策划在登录后免费;图片和视频生成需要当前报价所需积分与账户权限。
打开A+详情页 查看价格与积分