通知短信常见问题集

通知短信是面向已注册/已产生业务关系的用户，由业务事件触发或按计划下发的服务提醒类短信，内容为用户本人业务数据的告知，不含营销推广。典型形态：【某某商城】您的订单 ${orderId} 已发货，预计 ${date} 送达。

• 物流履约：发货提醒、快递派送、签收通知；
• 账户服务：账单出账、还款提醒、账户变动、密码修改成功通知；
• 订单状态：下单成功、支付成功、退款到账、订单取消；
• 服务提醒：预约确认、课程/会议提醒、会员到期、系统维护公告；
• 工单与告警：面向企业内部人员的告警通知、工单流转通知。

变量是模板中可动态替换的占位符，如 ${orderId}、${date}。发送时由业务方传入实际值，平台替换后下发。变量规范：

• 变量名用英文，语义清晰（避免 ${a1} 这类无意义命名）；
• 单个变量长度通常限制 ≤ 20 字符（以平台规则为准）；
• 变量值不得包含签名、退订语、URL 等违规模板要素；
• 变量数量一般 ≤ 5～10 个，过多会影响审核与拼接性能。

超过单条短信字数上限的短信，会被自动拆分成多条子短信（用户手机上自动合并显示）。计费按拆分后的条数计算，具体拆分规则见「计费相关」章节。通知短信因带订单号、时间、明细等信息，很容易超过 70 字触发长短信计费，是账单超预期的主要原因。

• 清晰的业务主体与事件描述（谁、发生了什么）；
• 关键业务数据通过变量呈现（订单号、时间、金额等）；
• 必要的后续动作指引（如「详情请查看 App 内订单页」）；
• 内容与「通知」类型一致：纯服务告知，无促销话术；
• 不含敏感词、不含 URL（少数平台允许已备案短链，需单独申请）。

标准示例：【签名】您购买的订单 ${orderId} 已于 ${time} 发货，物流公司：${company}，运单号：${trackNo}。如有疑问请联系客服。

1. 内容含营销话术（「限时优惠」「点击参与」等）——应改走营销类模板；
2. 变量值描述不明确（审核无法判断变量将填什么内容）；
3. 变量格式错误、未定义或嵌套；
4. 签名与模板不匹配或签名未审核通过；
5. 内容涉及金融、教育、医疗等敏感行业但未提交资质；
6. 含有 URL、二维码引导等未备案元素。

不可以。模板一经审核通过，正文与变量结构均不可在线修改，只能新建模板重新送审。因此建议：

• 模板设计时预留合理变量位，减少后续改动需求；
• 用「版本号」命名模板便于灰度切换（如 NTC_SHIP_V2）；
• 新旧模板切换时保留旧模板 1～2 周观察期，避免在途发送受影响。

建议按业务事件而非「一个业务一套万能模板」来拆分：发货、派送、签收分别建模板，好处是内容精准（审核易过）、变量明确、问题定位方便。避免用一个「大杂烩」模板通过变量拼出完全不同的内容——这是审核驳回与通道拦截的高危模式。

单条短信正文上限：70 字（含签名与标点，纯中文场景）。超过后按长短信拆分计费：

• 71～134 字 = 2 条；135～201 字 = 3 条，以此类推（每 67 字一条）；
• 含英文/数字时按编码规则折算，具体以平台计算器为准；
• 建议把通知控制在 1 条（≤70 字）内：省成本、到达率更稳、用户阅读体验更好。

可以。签名代表发送主体身份，与短信类型无关——同一个签名下可分别申请验证码、通知、营销三类模板。模板必须归属某个已审核通过的签名，发送时携带的签名要与模板归属一致。

审核时效一般 2 小时内（工作日）。

• 长度一般 2～12 个字符，中文为主；
• 必须与资质材料中的名称存在明显归属关系；
• 禁止使用涉政、涉黄、误导性词汇，禁止冒用知名品牌；
• 签名计入正文字数（影响长短信拆分）；
• 多品牌企业应为每个对外品牌单独申请签名，切勿混用。

可以，同一企业主体可申请多个签名（如集团下多个产品线），每个签名需独立提供归属证明。注意：签名数量部分平台有限额，且每个签名独立审核、独立统计到达率与投诉率——管理时建议建立「签名-模板-场景」台账。

支持。典型批量请求：

POST /sms/notice/batch-send
{
  "sign": "密达云通信",
  "templateId": "NTC_SHIP_V2",
  "recipients": [
    { "mobile": "13800138000", "params": { "orderId": "A12345", "time": "08-31 10:00" } },
    { "mobile": "13900139000", "params": { "orderId": "A12346", "time": "08-31 10:05" } }
  ],
  "requestId": "batch-uuid-xxx",
  "scheduleTime": null          // 可选：定时发送
}

单次请求的号码上限常见为 1000～10000 个（以平台文档为准），更大批量请分页循环提交。

两级结果要分开看：

1. 提交阶段：同步返回每个号码的提交结果（格式错误、频控、黑名单等会在这一步失败，不扣费）；
2. 投递阶段：提交成功的号码，最终送达与否以状态报告（回执）为准，通过回调或查询接口逐号码获取。

务必为每个号码记录 requestId + mobile + 提交结果 + 回执状态，这是批量对账与补发的基础。

• 每次批量任务生成唯一 requestId，任务重试时复用同一 ID，平台按幂等键去重；
• 业务侧对「同一事件只发一次」做强约束：如发货事件以 orderId + 事件类型 做幂等键，避免上下游重试导致重复通知；
• 定时任务加分布式锁，防止多实例并发触发同一批任务。

典型速率为数百～数千条/秒（取决于通道与配额）。支持速率控制：

• 接口参数指定 speed（条/秒）平滑下发，避免瞬时打爆通道；
• 配合定时任务与分批提交，实现错峰；
• 大批量建议夜间低峰期发送（非时效类通知），到达率与成本更优。

有，但比验证码宽松。常见平台侧限制：

业务侧仍应做用户维度降噪：如同一订单的多状态变更合并通知，避免「短信轰炸」引发投诉。

支持。提交时传 scheduleTime 即可在指定时间自动下发（常见精度为分钟级）。注意：

• 定时任务在到期前可撤销/修改（以平台能力为准）；
• 避免将大量定时任务设定在同一时刻（如整点），会造成瞬时拥塞；
• 节假日前的定时发送要考虑运营商拥塞窗口，提前 30～60 分钟更稳妥。

按 1000 条/秒的提交速率，纯提交约 100 秒；但实际「全部送达」取决于通道吞吐与运营商处理能力，通常以分钟～小时计。影响因素：

• 账号 QPS 配额与通道带宽；
• 是否设置了限速参数；
• 运营商时段拥塞（晚高峰、节假日）；
• 号码分布在三大运营商的比例。

大促场景请提前报备量级，平台会做通道扩容。

会。拥塞时运营商优先保障验证码 > 通知 > 营销。通知短信在极端拥塞下延迟可能明显上升（分钟级到小时级）。对时效敏感的通知（如告警、验证类通知）可与平台沟通使用高优先级通道。

• 避开：早 8 点前、晚 22 点后（扰民投诉高发）、整点拥塞窗口；
• 推荐：9:00–11:30、14:00–17:30、19:00–21:00；
• 非时效类批量通知（账单、对账单）建议 22:00 后～次日 7:00 前的夜间低峰错峰发送；
• 紧急告警类不受此限，但应控制频次。

1. 提前 3～5 个工作日向服务商报备发送量级与时间段，申请扩容/独享通道；
2. 号码列表预清洗（去重、去空号、去黑名单），降低无效消耗；
3. 压测自身发送链路与队列吞吐；
4. 准备分批发送预案与熔断开关（投诉率异常时快速停发）；
5. 活动当天安排值班监控到达率与投诉指标。

通知短信到达率低于验证码是正常的：号码库中沉淀的空号、停机、销号比例更高。老用户运营类号码库实测到达率 85%～90% 也很常见，应以自家号码库的基线做监控阈值。

回执一般在提交后秒级～30 分钟内返回；批量场景下部分回执可能延迟到 2 小时。约定：

• 超时（常见 2 小时）无回执 → 记为「未知」，不并入成败统计；
• 未知比例异常升高 → 优先排查回执链路而非通道；
• 对账口径统一用「回执终态」，避免「提交数 vs 回执数」混算。

1. 先分维度下钻：按运营商、模板、时间段拆分失败率，定位是「单运营商/单通道」还是「全量」问题；
2. 看错误码分布：UNDELIV 主因是空号/停机（号码库问题），还是网关拥塞（通道问题）；
3. 查自身变更：当天是否改过模板、变量、号码来源；
4. 实测验证：三大运营商测试号码各发一条；
5. 确认通道劣化 → 联系平台切通道，并评估是否需要补发。

可以但要谨慎：

• 仅对「通道侧失败」（拥塞、网关错误）补发，且换通道重试；
• 空号/停机/黑名单类失败不补发（补发必然再失败，浪费成本）；
• 补发要有次数上限（如 1 次）与时间窗口（如 10 分钟内）；
• 时效性已过（如「10 分钟后开始的会议」）则放弃补发。

• 回调 URL 需公网可达、快速返回 200；
• 平台失败重推机制（1m/5m/30m 递增）确认已启用；
• 建立定时对账兜底：每 10～30 分钟按时间段批量拉取回执补偿；
• 对账任务与回调共用同一幂等键去重，防止状态覆盖错乱。

分情况：

• 纯服务必需类（订单、物流、账单、安全提醒）：一般无需退订语，用户也未主动订阅之说，属合同/服务关系告知；
• 订阅提醒类（内容订阅、资讯推送、会员营销倾向的通知）：建议加「退订回T」，并尊重退订；
• 存在争议空间的内容（活动预告、召回通知）——稳妥做法是加退订语或走营销类模板。

取决于通道与黑名单机制设计：

• 若退订作用于签名维度黑名单 → 该签名下所有短信（含订单通知）都会被拦截，客诉高发；
• 规范做法是分类隔离：营销退订只拦营销类，服务必需类通知不受影响（或单独提供关闭入口）；
• 被误拦用户可通过客服或指定指令解除黑名单。建议在用户协议中明确「订单物流等交易通知不可退订」。

来源：用户回复退订、12321/运营商投诉、内容违规处罚、平台风控标记。降低方式：

• 控制发送频次与时段，避免打扰；
• 通知内容精准、有价值，减少「垃圾感」；
• 营销与通知严格分类，营销必须带退订并尊重退订；
• 监控投诉率指标（如万分之一阈值），异常时立即停发整改。

1. 模板/签名被驳回或下线；
2. 运营商抽检发现后关停签名甚至封禁账号；
3. 用户投诉率飙升，进入黑名单链路恶化；
4. 违反《通信短信息服务管理规定》，面临监管处罚。

典型违规手法（均会被识别）：通知模板塞入「优惠券」「限时」「立即抢购」；用订单通知尾缀加推广语；变量中夹带营销文案。

交易/服务关系内的通知（订单、账单、安全提醒）可默认发送，这也是用户的合理期待；但：

• 非交易必需的订阅型通知，应在注册/设置环节提供用户可控的开关；
• 不得以「服务通知」名义向从未发生业务关系的号码推送内容；
• 收集手机号时需符合《个人信息保护法》的告知同意要求，明确用途含「服务通知」。

短信明文传输，原则上只放「无害摘要」：

• 可放：脱敏订单号（尾号）、粗粒度金额、时间；
• 不放：完整卡号、密码、验证码、身份证号、完整住址；
• 详情引导用户到 App 内查看（「详见 App-我的订单」）；
• 发送日志与对账文件中的手机号、订单号同样需脱敏存储，保留期 ≥ 180 天但访问受控。

• 金融：需金融牌照或业务备案证明，还款/账单类措辞受严格审核；
• 医疗：挂号、报告类通知需医疗机构资质；
• 教育：课时、开课通知需办学/培训资质；
• 这些行业建议在申请签名/模板时一次性备齐资质，避免反复驳回延误业务。

• 拆分阈值从第二条起是 67 字（需预留长短信协议头）；
• 英文数字按 160 字符/条（拆分后 153/条），中英混排按 Unicode 计；
• 用户手机上仍显示为一条合并短信，但计费按条数；
• 变量替换后的实际内容才决定条数——模板 68 字、变量填 5 个字，实际按 73 字 = 2 条计费。

• 不扣费：提交阶段失败（格式错误、频控、模板/签名失效、余额不足拦截）；
• 扣费：提交成功的每一条（含长短信按拆分条数），无论用户最终是否收到；
• 空号/停机的 UNDELIV 通常已产生通道成本，正常计费；
• 通道故障导致的批量失败可凭发送记录申请返还（以服务商政策为准）。

1. 正文控制在 70 字内（含签名），单条化是最大的成本杠杆；
2. 号码库定期清洗：去重、去空号（空号检测）、下线 6 个月以上沉默号码；
3. 按事件去重合并，同一订单多状态只发关键节点；
4. 到达率监控 + 通道优选，减少为低质量通道买单；
5. 套餐包/阶梯价谈判：批量月量稳定可获折扣；
6. 配置余额预警（低于 20% 告警），防止余额耗尽造成业务中断。

按天对账，核心字段：requestId、批次ID、手机号、模板ID、计费条数（长短信拆分后）、提交时间、回执终态、费用。

• 重点核对「计费条数」：用实际替换后的正文重算字数，与服务商账单比对（长短信错算是最常见差异源）；
• 差异项分类：有请求无账单、有账单无请求、条数不符，分别提工单；
• 保留明细 ≥ 180 天。