林静姝
更新：2026-07-24
SaaS 控制台上写着"已发送：100万条"。财务报表显示"已支出：7,500 美元"。客户成功团队却反馈："一半用户根本没收到验证码"。
从 API 调用到用户锁屏界面之间的某个环节，8 万多条消息就这样悄无声息地消失了，而后台的投递报告依然显示"98% 成功"。据 AWS End User Messaging（2025）介绍， 100% 送达率在全球电信网络的架构下本就是一个无法实现的目标。真正的问题在于，大多数 SaaS 团队从一开始就盯错了指标。
本指南将拆解 SaaS 团队常用的四个关键杠杆，帮助您把短信送达率从"看起来还行"提升到经过验证的 98% 以上。这四个杠杆会按影响程度依次展开，全部基于运营商处理 A2P 流量的真实机制，而非理论假设。
对 SaaS 平台来说，短信送达率从来不是一个可以先放一放的指标。它直接决定了用户能否顺利完成注册、能否走完支付流程，也决定了有多少用户会悄无声息地流失。
为什么 SaaS 短信里"已发送"不等于"已送达"
大多数短信 API 会返回四种状态：已发送、已送达、失败、未送达。这四个状态含义各不相同，而混淆它们，正是大多数团队在优化短信送达率时踩的第一个坑。
已发送只说明一件事：您的 API 请求已被接受，消息已提交给服务商。仅此而已，离用户手机还远着呢。
已送达说明运营商的短信中心（SMSC）已确认接收这条消息，但这不等于消息已经到达设备。如果手机处于飞行模式、没电关机，或所在基站正在拥塞，消息可能会在 SMSC 队列里滞留数小时才真正送达，也可能永远送不到。
失败通常意味着出现了硬性拦截：号码无效、被运营商拒绝、内容被过滤等等。
未送达则更暧昧一些，不代表被系统立刻拒绝，只说明消息进了系统，但没能在统计窗口内完成投递。
CleverTap（2025）的数据显示，健康的短信送达率一般在 95% 到 98% 之间，科技、金融、医疗这类对时效敏感的行业通常能稳定在这个区间甚至更高。如果您的送达率跌破 95%，就该按顺序排查号码列表、路由配置和服务商这三个环节了。一旦低于 92%，用户激活率会直接受影响。
按 SaaS 常见规模算一笔账：如果每周发送 50 万条 OTP，3 个百分点的送达率差距绝不是可以四舍五入忽略的误差，而是意味着 1.5 万名用户仅仅因为没收到验证码就没能完成注册。而这些人里，绝大多数不会给客服写邮件反馈，他们只会默默流失，您甚至都不知道原因。
接下来我们就拆解：送达率跌破 95% 之前，问题究竟出在哪个环节。
SaaS 短信送达率跌破 95% 之前，哪些环节先出了问题
大多数 SaaS 团队的送达率优化之所以停滞不前，是因为只处理了表面症状，没有找到根本原因。要真正把送达率提上去，得先解决下面这五个故障点，它们是导致送达率跌破 95% 的最主要原因：
1. 无效联系人列表
无效联系人列表是最隐蔽、也最烧钱的问题之一。列表里只要混入停用号码、过期号码或格式错误的号码，短信大概率发不出去，但您的发送额度照样被扣。
国家代码缺失或填错、号码保存格式不规范，都会引发同样的问题。建议定期校验目标号码、清理老旧联系人列表，并保留用户授权记录，避免为发往无效号码、停用号码或非手机号码的短信白白买单。在 SaaS 的发送规模下，哪怕只是一小部分过期注册数据，也足以拖累整体送达率。
2. 聚合商多跳路由
路由链路是第二个隐性因素。大多数短信服务商并不会把消息直接送到运营商，而是先转给聚合商，聚合商再转给批发合作伙伴，中间可能还要再经过一道中转，最后才落到 SMSC。
据 SMS-Magic（2025）介绍，聚合商为了压低成本，经常会让消息经过多个中间服务商转发。每多一道中转，延迟和误路由的风险就跟着叠加一次，而"已送达"这个笼统的状态，根本不会告诉您中间到底经过了几道手。
简单说：链路里的中间商越多，送达就越不稳定，这是大多数团队没意识到的隐藏成本。
3. 公共短链被运营商拦截
如果短信里带着 bit.ly、tinyurl.com、rb.gy 之类的公共短链，很可能直接被拦。GoHighLevel 的帮助文档（2026）就明确记录了 T-Mobile 禁止 URL 循环跳转和多重重定向的规定，AT&T 也是直接屏蔽公共短链域名。下面这条来自 Reddit 用户（2024）分享的 T-Mobile 客服回复，可以直观感受一下运营商的态度：
这类限制是运营商在网络层面统一执行的规则，不管您的发件方信誉再好、注册再合规都不例外。归根结底还是信任问题：在运营商眼里，链接的可信度本身就是一条路由规则，直接决定短信能不能送出去。
4. 未注册的 10DLC / A2P 发件号码
10DLC 未注册，或者 A2P 发送方案配置不规范，也是常见的送达率流失点。美国运营商要求先完成品牌和活动注册，才会以完整吞吐能力和相应信任等级来处理您的流量，这正是 CTIA 消息框架和 TCR（The Campaign Registry）的核心要求。
运营商希望看到的是经过授权的企业流量，而不是来路不明的批量群发。自 2025 年 2 月起，来自未注册 10 位长号码（10DLC）的 A2P 流量，已经在 T-Mobile、AT&T、Verizon 网络上被过滤或直接拦截。
换句话说，如果您现在还在用未注册号码发 OTP，一部分消息可能在到达 SMSC 之前就已经被拦下了，而您的送达报告不会告诉您原因，它只会显示一个不那么好看的百分比。
5. 容易触发垃圾短信拦截的内容和编码问题
内容层面的影响，往往比团队愿意承认的要大得多。运营商早就部署了高级过滤器来识别疑似垃圾短信，大量使用大写字母、明显的促销话术，以及不兼容 GSM-7 的字符（花式引号、带重音符号的字母、表情符号），都会给过滤器发出垃圾短信信号。
如果消息用了 Unicode 而不是 GSM-7 编码，单条短信可能会被拆成两段甚至更多。这不仅会改变消息指纹、增加被过滤的风险，哪怕内容本身完全合规也一样。
对大多数 SaaS 团队来说，先把路由这个环节优化好，往往就能拿到最大的一波送达率提升。接下来就具体说说怎么做。
把 SaaS 短信送达率提升到 98% 以上的优化体系
短信 API 送达率优化从来不是一次性的修复，而是一套持续运转的体系。这套体系同样支撑着短信营销自动化这类需要长期稳定运行的场景。
以下六项措施，正是送达率停在 96% 的团队和冲到 99% 的团队之间的真正差距：
1. 运营商直连路由 vs. 聚合商路由
从 API 调用到 SMSC 之间的中转环节越少，可能出问题的地方就越少。条件允许的话，应该优先选运营商直连，而不是默认走聚合商链路。
运营商直连能减少中间商带来的风险，降低延迟，提升链路可观测性，报错信息也更清晰。很多以成本为导向的聚合商，会为了利润空间牺牲路由质量，这对普通营销短信或许还能接受，但对 OTP、支付确认、安全提醒这类事务性 SaaS 消息来说，这种权衡完全不划算。
2. 按国家/地区和运营商做智能路由
不同市场的表现差异非常大。同一套系统，在德国可能 3 秒内就送达，到了印度尼西亚，用户可能要等上 40 秒以上才能收到。
造成这种差异的，是各地运营商基础设施和内容过滤策略的不同，也和您的短信 API 到目标网络之间要经过几道路由跳数有关。
AWS End User Messaging（2025）也提到，全球短信投送依赖的是因国家/地区而异的电信路由路径以及运营商之间的互联关系，这意味着靠一条固定的默认路由，不可能在所有地区都表现稳定。
智能路由要解决的正是这个问题：根据地理位置和运营商（MNO）动态选择传输路径。高级路由算法会实时评估收件人所在地和当前网络状况，为每一条消息挑选最优路径。比如某条通往东南亚某运营商的主路由开始排队或送达变慢，流量会自动切到下一条更优的线路。
对需要同时面向多个市场发送 OTP 的 SaaS 团队来说，这种按条、按运营商动态决策的能力，能在某些路由临时抽风的情况下，依然把用户激活率稳住。
3. 品牌短链
尽快把公共短链换成品牌短链，不只是因为更好看，更是因为点击率和送达表现都会明显更好，被运营商拦截的风险也更低。Rebrandly（2026）的报告显示，品牌短链带来的点击量最高能比通用 URL 提升 39%。
点击量的提升，本质上反映的是运营商对这类链接更高的信任度。当链接域名和发件身份一致时，被过滤系统误判为钓鱼短信的概率会更低，用户自己也更愿意点开。
4. 双重确认订阅
双重确认订阅要求用户输入号码后再进一步确认接收验证短信。这一步能在号码填错导致后续送达失败之前就把问题揪出来，同时清理掉那些始终不确认的僵尸联系人。它也能形成一份可留痕的用户授权记录，既满足 TCPA 之类的合规要求，也有助于提升运营商对您发件方的信任评分。
对 SaaS 而言，这一步的价值不只是合规。更完善的用户授权机制通常意味着更少投诉、更少被拦截，长期来看也是在给自己的发件信誉攒分。
5. GSM-7 编码
只要出现一个不在 GSM-7 字符集里的字符，整条短信就会被迫切换成 Unicode 编码，每段容量从 160 个字符骤降到 70 个字符，分段数量因此翻倍甚至变成三倍，成本也跟着水涨船高。
更麻烦的是，这还会改变消息指纹，让运营商的审查更严格。建议检查一下自己的短信模板里，是不是藏着花式引号、长破折号，或者不必要的非拉丁字符。 这不是说完全不能用非拉丁字符，而是要清楚哪些写法会在不知不觉中变成拖累送达率的隐性成本。
6. 实时错误码监控
如果送达日志里只有笼统的"失败"两个字，那这份日志基本没什么排查价值。错误码 30007（运营商违规/内容被过滤）背后的原因，和 30003（号码无法送达）或 30006（固定电话）完全是两码事。
每一个错误码对应的根因和解决方式都不一样。像 EngageLab 这类平台能实时展示精细到运营商层级的错误码，团队因此能在送达率真正塌下去之前，先判断问题出在内容还是运营商侧。
把这六项措施都落实到位，数字才会真正好看起来。不过短信送达表现里，还有一个大多数 SaaS 团队从没认真衡量过的维度。接下来就聊聊这个。
出海 SaaS 如何降低跨境短信送达延迟
有一个指标，往往要等到它拖累用户激活率的时候，团队才会想起来去追踪：送达延迟。对 SaaS 来说，只盯送达率只看到了一半的问题，延迟才是经常被忽略的另一半。
您的送达率仪表盘可能显示 98%，但用户激活率还是可能明显下滑。原因很简单：用户点了"发送验证码"之后等了 47 秒才收到 OTP，哪怕系统把它标记为"已送达"，对整个验证流程来说，这条短信也已经等于没送到。
大多数验证流程会在 30 到 60 秒后超时。超过这个时间窗口才到达的消息，即便运营商记录为送达成功，对用户体验的伤害其实已经造成了。
延迟会在整条链路的每一层不断累积，这也是为什么送达延迟应该被当作一个独立的优化目标来看待。AWS End User Messaging（2025）也提到，全球电信基础设施带来的送达时延波动，不是任何一家服务商能单独控制的。
但路由层是您最能掌控的部分，也恰恰是大多数 SaaS 平台最容易忽略性能优化的地方。
这里的差距主要来自两种架构：
- 每个地区只用一条固定路由： 服务商为每个国家配一条路由，一直用到出故障为止。这是以聚合商为主的平台的默认做法，优化的目标是成本，而不是送达速度。一旦这条路由在高峰期或运营商维护期出现延迟，发往该地区的所有 OTP 都会一起变慢。
- 智能多路由故障切换： 平台会按运营商和地区持续监控路由表现，根据实时延迟信号动态切换流量。如果发往印尼某运营商的主路由排队超过 40 秒，系统会自动把流量切到备用路由。
这两种架构之间的延迟差距相当明显。在亚太、中东非洲和拉美市场，以聚合商为主的路由通常会带来 20 到 60 秒的额外延迟。
SMS-Magic（2025）也指出，路由每多一次中转，延迟和风险都会跟着叠加，这种影响会在多跳链路里持续累积，而同样的目的地，走运营商直连往往能在 5 秒内完成送达。如果是时效要求不高的营销短信，这点延迟或许无所谓；但如果您的用户激活流程要靠验证码在用户放弃之前及时送达，这个差距就完全不能将就。
EngageLab 在亚太、中东非洲和拉美地区都与本地运营商建立了直连通道，原因很简单，这些地区恰恰是聚合商为主的平台最容易出现延迟波动的地方。
当 SaaS 团队向印尼、泰国、尼日利亚或巴西用户发送 OTP 时，这层基础设施上的差异，往往就决定了用户是顺利完成注册引导，还是卡在验证码这一步直接放弃。
"送到了，但太晚了"这种问题，会在您毫无察觉的情况下悄悄拉低激活 KPI。只看送达率是发现不了的，得靠延迟监控才行。
规模化业务选型短信基础设施时该问的六个问题
大多数团队都是踩过第一次运营商拦截或延迟事故之后，才开始问对问题。但如果能在 SaaS 短信平台对比和供应商选型阶段就问清楚这些，就能在问题真正造成损失之前提前排雷。
下面是围绕六个关键问题的供应商评估清单：
问题 1：运营商连接方式，是直连还是走聚合商？
直接要求对方提供按地区划分的运营商直连清单。任何答不上来这个问题的服务商，大概率是在走聚合商链路。这不代表它不合格，但至少能让您清楚， 自己的延迟和可靠性风险主要来自哪里。
问题 2：能提供哪些错误码，精细到什么程度？
一句笼统的"失败"，保护的是平台，不是您。您需要的是运营商级别的错误码，比如 30007、30003、30006 这类具体代码，并且能按目标运营商、消息类型和时间段做拆分。 看不到这些细节，就没法真正修复问题。
问题 3：有没有实时送达监控仪表板？
不是那种第二天才能看到的延迟报告，而是能按运营商、国家、消息类型筛选，并且接近实时更新的监控视图。送达问题不会等您的 报表周期出结果，它们在几个小时内就能累积成规模。等日报显示异常时，用户往往已经流失了。
问题 4：故障切换架构实际跑起来是什么样的？
问清楚触发切换的条件是什么，切换速度有多快，能不能拿出一次真实的触发记录。真正具备智能故障切换能力的平台，应该能直接给您看相关日志。
问题 5：能提供哪些区域的合规支持？
每个市场都有自己的一套合规要求，发件人 ID 注册、印度的 DLT 合规、泰国的 PDPA、南非的 POPIA 等等。如果平台没法按国家跟踪这些合规要求， 您每进入一个新市场就要重新踩一遍坑。
问题 6：SLA 保的是送达率，还是只保可用性？
可用性 SLA 很容易达标，平台可能一直"在线"，但实际只送达了 40% 的消息。只有把送达率写进 SLA，供应商才会真正对结果负责，而不是对"服务是否在跑"负责。
EngageLab 的短信送达监控面板会展示上述六项指标，包括按运营商拆分的错误码明细，以及分地区的合规状态。大多数 SaaS 团队往往要等到第一次撞上运营商拦截，才意识到这些功能有多重要。
在真正开始规模化发送之前，不妨先看看EngageLab 短信 API 文档，了解一下 EngageLab 是怎么搭建这套送达基础设施的。
SaaS 团队规模化前最常问的短信送达率问题
1. SaaS 平台的短信送达率多少算合格？
行业基准一般在 95% 到 98% 之间。如果发的是事务性消息（OTP、支付确认、安全提醒），标准还要更高一些：低于 97% 就该检查路由和号码列表质量了，低于 95% 则说明很可能存在运营商主动过滤或号码列表质量问题。对 2FA 这类关键业务场景，建议把目标定在 99%，并且送达率和延迟要同时盯着看，缺一不可。
2. 短信显示"已送达"，用户却说没收到，为什么？
最常见的原因，是 SMSC 确认接收和消息真正到达用户设备之间存在时间差。"已送达"只说明运营商的 SMSC 接受了这条消息，不代表它已经出现在用户手机上。飞行模式或关机状态下的手机，会让消息一直滞留在 SMSC 队列里，直到超时。
运营商侧的过滤也可能在 SMSC 确认接收之后才把消息拦下来；如果延迟太严重，OTP 在验证时限过后才送达，效果上和没送达没有任何区别。
3. 注册 10DLC 能提高送达率吗？
对美国 A2P 流量来说，通常能。10DLC 是美国运营商认可的应用到个人消息传递标准，品牌和活动是否完成注册，直接影响运营商给您分配的信任等级和吞吐能力上限。注册不代表万事大吉，但确实能提高您可用的流量天花板。
4. 规模化发送时，SaaS 平台该怎么监控送达情况？
常见做法是结合三种手段：基于 API 的实时 Webhook 回调、运营商提供的详细送达回执（DLR），以及自动化监控工具。这些系统不会只盯着"已送达"这一个笼统状态，而是把多种信号汇总起来看，包括运营商级 DLR、具体错误码（比如代表内容被过滤的 30007，或代表号码无法到达的 30003），以及发送和接收之间的延迟，从而准确定位消息到底卡在了哪个环节。
写在最后：把送达率优化真正落到技术栈里
能把送达率稳定做到 98% 以上的团队，基本都是按同一个顺序做对了四件事：先修路由，再清理内容和规范链接，然后把号码正确注册和分流，最后是持续做好运营商级监控。
大多数仪表盘都漏掉的一个关键指标是送达延迟。它是短信送达能力里最容易被忽视的一半，也是悄悄拖垮 SaaS 激活 KPI 的幕后推手。如果有 3% 的用户因为验证码等了 47 秒才到而直接放弃了验证页面，那 98% 的送达率数字，其实什么都说明不了。
如果您正在评估短信平台，建议重点看这几点：运营商直连路由、运营商级错误码、故障切换能力、区域合规覆盖，以及一个真正能信得过的送达监控视图。这些能力，EngageLab 都能提供。
