模板审核门控与计费单元分类

在业务起量时，没有审核门控与命名计费单元的模板，会让预付钱包在无人能定价的「成功发送」中迅速烧光。买家必须在生产扣款前证明审核状态为「已批准」且计费单元已映射，而不是等财务部门打开月末账单才来核对。本页面即为此类门控；在通道上线前的模板目录则是其姐妹买家路径。

相关链接：上线模板 catalog 目录先于通道正式发布、预付账本中的欺诈拦截燃烧行、同一账本上的扣款行与送达状态、生产 OTP 之前的速率限制。

IOSOR 是白标预付系统。USD 20 可在单个模板 ID 上资助一个审核门控试点；接近 USD 1,000/month 的软审核会将缺失的计费单元定价为对账债务。客户仅会看到白标审核宏指令。

审核状态是硬门控而非标签

草稿、审核中、已批准、已拒绝以及已退役都是关乎资金的状态。只有「已批准」的模板才能进行生产发送。「已拒绝」和「草稿」会以诚实的状态失败关闭——绝不会静默回退并燃烧到其他分类中。优先建立目录：上线模板 catalog 目录先于通道正式发布。软阈值 USD 1,000/month 将「审核中发送」视为量化债务；USD 20 则证明被拒绝的模板无法扣款。

在扣款发布前映射计费单元

财务人员必须在扣款行上读取到产品在目录中设置的相同计费单元。账本邻居：同一账本上的扣款行与送达状态 以及 预付账本中的欺诈拦截燃烧行。错误的分类会将 OTP 支出变成「杂项消息」的无主传说。

审核或分类缺失时失败关闭

缺少审核状态 → 不发送。缺少计费单元 → 不发送。未知模板 ID → 不发送。共享状态词可杜绝英雄代码：产品与财务的共享状态语言。速率限制依然适用于「已批准」的 ID——审核门控不能替代 生产 OTP 之前的速率限制；它位于量化语言的前方。

产品、财务与运维共享一份证明

产品：合法的「已批准」模板能否在映射的计费单元下完成？财务：每行扣款是否在 UTC 窗口内携带了模板 ID 和计费单元？运维：能否在不翻找 Slack 历史记录的情况下导出被拒与分类不匹配的数据？一份证明胜过三方争论。当拒绝隐藏支出时保持燃烧诚实：预付账本中的欺诈拦截燃烧行。

审核门控与单元分类买家检查清单

1. 生产发送是否要求「已批准」——草稿和审核中是否被拦截？
2. 已拒绝和已退役是否以诚实状态失败关闭？
3. 每个目录 ID 是否精确映射到一个计费单元？
4. 扣款行是否显示财务能够连接的模板 ID 与计费单元？
5. 覆盖是否经过命名、有时效且由新的冒烟测试关闭？
6. 计费单元为空时，软体量语言是否被阻止？

任何「否」都会让审核门控保留在草稿中。

从 IOSOR 开始

打开 IOSOR 控制台并导航至模板路由规则，以验证审查关卡已设置为故障关闭。在引导实时流量之前，将每个模板 ID 映射到其明确的计费单元类别，无论是短信分段、模板单元、会话单元还是验证尝试。发送包含草稿或未映射模板 ID 的测试调度，以确认网络钩子返回明确的拒绝关卡，而不是允许回退扣款。

IOSOR 要点

本文证明了模板审查状态和计费单元类别映射必须在执行扣款之前作为不可变的运行时关卡。强制执行明确的批准状态要求以及确定性的单元分类，可以消除财务不匹配，并防止未批准的资产泄漏到生产交付队列中。

对于缺失的审查状态或未映射的单元类别，请立即执行故障关闭，以在产品、财务和运营部门之间维护单一的证明包。在实时执行期间，切勿允许静默回退路由或模糊的目录标签绕过模板治理。