用户下完单后，通常只想尽快知道一件事：订单现在到哪一步了？

付款成功后，订单有没有成立？预约时间变了，自己需不需要重新确认？快递迟迟没更新，是商家还没发货，还是运输途中出了异常？这些问题一旦没有明确入口，用户往往会翻订单页、问客服，甚至重复下单。

短信适合补充这类关键信息。企业应从订单系统的状态变化中挑出会影响用户判断、行动或权益的节点。用户看完短信，应能知道订单处于什么状态、自己是否需要处理、下一步去哪里看。

先定一条标准：这次变化会不会影响用户？

订单系统里的状态通常很多。创建订单、风控校验、库存锁定、仓库拣货、打包、交接承运商、运输中、签收回传，后台可以记录得很细。用户无需为每个内部动作接收一条提醒。

团队可以先用三个问题筛选。

1、用户是否需要马上做一件事？

例如待支付订单临近关闭、预约服务需要确认时间、收货地址需要补全、售后申请需要补资料。这类提醒直接关系到订单能否继续推进，短信可以把需要做的动作和官方入口说清楚。

2、订单状态是否影响用户的核心预期？

支付成功、商品已发货、服务时间改期、退款已处理、售后结果已出，都会影响用户对订单的判断。用户未必一直打开App或订单页面，企业可以用短信补一条确认。

3、用户是否会因为这次变化主动来问客服？

配送异常、预约取消、商品缺货、订单关闭等情况，用户发现得越晚，追问和投诉越容易集中到客服。企业在状态确定后给出说明和下一步安排，客服也少一次从头解释。

订单流程里，优先考虑这6类节点

不同业务的订单链路不一样，但下面几类节点通常更值得单独配置提醒。

1、订单提交或支付完成

用户完成支付后，需要确认交易是否成立。短信可以写明订单已经提交或支付已经确认，并引导用户到官方订单页查看详情。

企业要按实际业务状态写内容。支付渠道返回成功，不等于商家已经完成后续履约；订单仍在校验或待确认时，短信不宜写成“商品即将发货”。

2、待支付订单临近关闭

用户选择了商品或服务，却没有完成付款时，企业可以根据自身规则发送一次支付提醒。短信里只需要说明订单的有效时间、需要完成的动作和官方支付入口。

这类提醒容易和营销内容混在一起。订单待支付提醒围绕用户已经发起的交易写，不要顺带加优惠活动、其他商品推荐或不相关的促销信息。

3、发货、服务开始或预约确认

实体商品交给承运商、上门服务已安排、线上服务即将开始，这些节点会改变用户的时间安排。短信可以告诉用户订单进入履约环节，并提供订单查询入口。

涉及预约的业务，还要写清服务日期、时间段和变更方式。企业没有确认服务人员、库存或时段之前，不要用短信给出确定承诺。

4、需要用户处理的异常

缺货、地址错误、配送受阻、预约资源不足、资料不完整，都需要用户及时决定。企业应在异常状态确认后发出提醒，直接说明问题属于哪一类、用户需要补什么或选择什么，再引导他进入官方页面完成操作。

短信不要堆满内部原因。用户需要知道的是订单怎么继续，不是仓库、支付或系统之间发生了多少次接口调用。

5、订单取消、退款或售后结果

订单关闭、退款发起、退款到账、换货发出、售后申请处理完成，都和用户的权益有关。企业可按业务实际进度发送确认，并明确用户可查询的订单号、服务单号或官方入口。

退款处理涉及支付渠道和银行到账时间时，短信不要随意写“立即到账”。团队应按已确定的处理状态和对外服务规则告知用户。

6、履约完成后仍需用户确认

有些业务在签收、服务完成或交付后，还需要用户激活权益、下载凭证、确认服务结果或处理后续问题。企业可以在这一步提醒用户，但内容要和本次订单直接相关。

用户已经完成交易后再收到多条重复通知，往往会把服务短信当成打扰。团队可以给同一订单设置发送上限，避免系统重试、状态回传重复或多个系统同时触发后连发相同内容。

这几类状态，通常不用单独发短信

有些动作只是企业内部流转，用户看了也无法判断下一步。比如库存锁定成功、仓库开始拣货、订单同步到ERP、物流接口刷新一次轨迹、客服修改了一条内部备注。这些状态留在业务系统里即可。

团队还要避免两个常见问题。

1、同一件事由多个系统重复发送。

订单中心发了“已发货”，物流系统又发一次，客服系统再补一次，用户手机里会出现三条近似内容。企业可以用订单号、业务类型和状态版本做去重，只保留一个对外发送来源。

2、状态还没稳定就提前通知。

订单刚进入退款流程、预约刚提交变更申请、物流刚收到异常反馈时，团队还没有明确处理结果。此时发出过度确定的短信，后续状态变化后只能再次解释。企业可以在信息确认后发送，或者明确写“已收到申请，处理进度请以订单页为准”。

一条订单提醒，用户需要看到什么

服务短信内容不宜复杂，但下面几项最好齐全。

1、企业名称或可识别的短信签名，让用户知道消息来自哪一笔交易。

2、订单当前状态，例如“已支付”“已发货”“等待补充地址”“退款已受理”。

3、必要的业务标识，例如订单尾号、订单号或服务单号。企业应控制展示范围，不要放完整手机号、身份证号、银行卡号等敏感信息。

4、用户下一步要做的动作。需要用户补资料、确认时间或查看结果时，直接说明动作和官方入口。用户不需要操作时，也应写清无需重复提交。

5、与当前订单相符的服务时限。企业有明确规则再写具体时间；没有确认处理时限时，不要写“马上处理”“很快到账”等无法兑现的话。

订单短信里的链接也要克制。企业可以引导用户回到自有App、官网、小程序、公众号或已有订单页查询。涉及支付、账户和身份信息时，更要避免用来源不明的短链接要求用户操作。

上线前，把订单状态和短信规则对一遍

产品人员先列出用户可见的订单状态，再标出每个状态下用户是否需要行动。运营和客服团队确认对外文案、服务时间和异常处理口径。技术团队最后把业务事件、短信模板、变量字段、发送回执和订单记录连起来。

测试时，团队不能只看短信是否提交成功，还要核对用户收到的内容是否和订单页一致。支付重复回调、用户多次点击、订单拆分、改址、退款撤销、多个系统同时更新，都是容易引发重复发送或错发的场景。

已经使用亿美软通企业短信的团队，可以先把订单提醒按支付、履约、异常、售后四类拆开，再与技术服务人员确认短信签名、模板内容、变量字段、发送回执和问题排查方式。订单中心、CRM或客服系统触发提醒后，客服查询订单时也应能看到相应的短信发送记录。

服务提醒和营销内容要分开

订单进度提醒属于业务管理和服务性通信短信息的常见场景。工业和信息化部现行《通信短信息服务管理规定》把操作验证、系统登录、业务提醒等列为业务管理和服务性通信短信息，并要求商业性通信短信息与业务管理和服务性通信短信息不得混用端口码号。

企业设计订单提醒时，应把本次交易的进度、用户需要完成的动作和售后信息写清楚。商品推荐、满减活动、会员促销等内容，另按商业短信的规则和用户同意情况处理。把两类内容混在一条消息里，用户难以分清订单状态，也会增加模板审核和运营管理的复杂度。

常见问题

1、订单支付成功后，短信和App推送都要发吗？

企业可以根据用户是否在线、业务的重要程度和已有通知习惯安排。用户正在App内完成支付时，页面反馈已经提供了确认；用户离开后需要保留一条可查询的交易提醒时，短信可以承担确认作用。两个渠道的文案应保持同一状态，避免一个写“支付成功”，另一个写“订单待确认”。

2、订单已发货后，短信里要写物流单号吗？

可以写必要的物流信息或查询入口，但要结合业务安排。用户最需要的是知道商品已经交付承运商，以及去哪里查看后续轨迹。物流单号过长或容易引发误操作时，也可以只保留订单号和官方查询入口。

3、订单异常后，多久发短信合适？

企业应在异常状态确认、且需要用户处理时发送。地址不完整、预约需要重新选择、资料需要补充等情况，越早通知越方便用户处理；内部系统还在核查原因时，先不要给出确定结论。

4、订单提醒可以带营销信息吗？

订单提醒应聚焦本次交易的进度和服务安排。促销、推荐和会员活动应使用对应的商业短信规则、端口和用户同意管理，不宜塞进订单通知里。