步骤 1
汇总店铺能够确认的配送状态、证明每个状态的证据(如承运商揽收扫描或签收确认)、在用模板,以及一个商家自定窗口内配送事件重复的订单。
店铺能确认的配送状态其实只有几个,但消息却在一些未经核实的事件上发出。本场景的具体任务是基于可靠证据生成配送状态通知。整个流程需为每个可确认状态写出对应消息,并设定重复事件时的抑制规则。
先替换所有 [方括号] 占位内容,再补充你真实的店铺数据和限制条件,最后粘贴到你常用的 AI 助手或 Spark 智能体里。Spark 会按本页定义的流程给出结构化的输出和验证方式。
你是一名 Shopify 运营专家。请帮我处理「shopify delivery notification app」这一问题,所属方向为「订单与物流通知」。
店铺背景:[填写品类、目标市场、目标客群]
处理范围:[填写商品、页面、客户、活动或日期范围]
可提供的数据:[填写已有资料]
请按以下方式工作:
1. 先说明完成该任务需要哪些关键数据,并标记缺失项。
2. 为每个可确认状态撰写一条消息并引用其背后的证据,要求证据齐备后才触发,使打单事件永远不会发出发货通知,同时按订单记录已发送的配送消息,使重复扫描被抑制。
3. 输出问题判断、建议方案、优先级、所需人工确认事项和验证方法。
4. 所有商品属性、指标、客户信息和营销结论必须以我提供的数据为依据;没有证据时请明确写“待确认”,不要猜测。
5. 如涉及发布、发信、改价、修改商品或账户操作,在我明确授权且工具已连接前,仅输出草案或操作步骤;完成操作后再报告已验证的结果。按输入、判断、交付三个阶段拆开执行,先保证每一步的输出,再进入下一步。
汇总店铺能够确认的配送状态、证明每个状态的证据(如承运商揽收扫描或签收确认)、在用模板,以及一个商家自定窗口内配送事件重复的订单。
为每个可确认状态撰写一条消息并引用其背后的证据,要求证据齐备后才触发,使打单事件永远不会发出发货通知,同时按订单记录已发送的配送消息,使重复扫描被抑制。
交付模板及其证据规则与抑制记录,把窗口内的订单重放一遍并列出消息声称但记录无法确认的状态,再对照所提供的记录确认每笔订单每个状态只收到一条消息。
覆盖判断依据、常见误解和必须准备的输入,让团队在真正动手之前先把前提对齐。
只有店铺能拿出承运商证据的状态才可以,通常是揽收、投递尝试和已签收,因为在未确认的状态上发消息等于承诺一个可能不会发生的运输动作;规格中没有证据规则的状态一律删除,而不是凭信任发送。
打单只说明包裹已备好,并不代表承运商已经拿到,此时发出发货通知会让顾客去查一条还不存在的轨迹;触发条件应为承运商揽收事件,打单事件只作内部记录。
每笔订单记录已发送过的配送消息,同一状态的重复扫描不再发送,因为重复的送达通知是物流自动化中最常见的投诉来源;真正的新状态一定会发送,因此投递失败后再签收会产生两条消息。
先优先看同主题的相似问题,或用相似度推荐扩展到跨主题但逻辑相近的其他场景。
Ciwi Spark 围绕 Shopify 商家常见的研究、投放、翻译和客户支持等流程,提供可以直接接入店铺的 AI 工具与智能体,减少反复写提示词的成本。