受理、送达、业务完成有什么区别？

先把技术状态与业务目标分开

企业发送消息通常有明确目的，例如通知订单变化、提醒预约或支持登录。即使消息发送过程顺利，业务目标也可能还需要用户进一步操作。

项目评估应先写清“什么叫完成”。登录成功、预约被确认和通知被发起各自属于不同结果，不能在报表中使用同一个模糊的成功率。

围绕一条消息建立对应关系

建议使用业务记录与发送任务之间的对应关系核对状态。接口具体提供哪些标识、回执和时间信息，需在对接时确认。

接口参考：发送请求成功不能代替最终回执状态，回执也不能直接证明用户阅读或业务转化。具体状态码按接入通道核对。

三个层次，分别能证明什么

一句话记住：受理 ≠ 收到，收到 ≠ 看到，看到 ≠ 办成。

举个常见情况：短信显示已送达，但用户手机开了免打扰、或者当时没在意，第二天才想起来处理。这时短信侧的结果是"送达成功"，业务侧的结果是"尚未完成"——两者都对，只是层次不同。

状态迟迟不返回，可以马上重发吗

不建议。没有拿到后续状态，不等于已经失败——可能只是状态返回延迟，也可能网络中断后稍晚才回传。

如果业务系统不做区分、一味重试，后果是：

● 用户收到两条一模一样的验证码，不知道用哪个

● 状态报告延迟到达后，与重试记录混淆，账目对不上

● 重复发送直接推高成本

建议做法：重试的条件、间隔时间、最多重试几次、超过次数后转人工还是直接放弃，都在项目阶段写清楚，并在测试阶段专门验证两种情况——重复提交和状态返回延迟。具体可用的状态字段与重试开关，需与服务商在对接时确认，不要默认系统已自动处理。

复盘时，按场景分开看

验证码、通知、会员服务三类短信，用户行为完全不同，混在一起看只会互相干扰：

国际短信还要多拆一层：按目的地国家、按语言版本分别核对。不同国家的状态返回规则不同，混在一起统计会掩盖单个市场的问题。