IOSOR 知识库

签署前运维团队必须确认的关键问题

在签署预付费 CPaaS 协议之前，运维团队必须针对 Webhook 心跳、JIT 号码采购、Live 状态标识及 STOP 退订处理提出明确质询 — 这是区别于 SMS API 开发指南的买家 checklist。

采购部门通常只关注价格并快速敲定合同，而运维团队往往继承了一个无法即时证明流量通畅的平台。在签署合同之前，运维团队必须明确心跳时效性、JIT 号码如何按需购买、Live 标识的真正含义以及 STOP 退订逻辑如何强制执行。这份清单旨在确保首日准备就绪，而不是一份讨论请求载荷与幂等性的 SMS API 技术文档。

IOSOR 首日准则：一条绿灯通行的上线跑道，需要最新状态的 Webhook 心跳、仅在 Vault 准备就序时才开启的 Live 标识，以及始终生效的合规闸门。如果不弄清楚这些问题就签字，买到的只是一套看起来开放但发送路径被堵塞的仪表盘。

在法务团队盖章之前，请务必将这些答案写入第一天上线准备清单中 — 缺少心跳机制是绝对不能接受的。

明确谁负责 Webhook 心跳时钟

要求明确定义何为新鲜的心跳状态，以及心跳过期时会发生什么。运维团队必须清楚知道当心跳延迟超过门限时会触发哪个告警、由谁来解除锁定。如果合同中从未指定心跳的责任归属，那么上线首日早晨的 traffic_ok 状态将变成不可预测的谜团。

向对方索取最近一次成功的冒烟测试路径证明，而不是仅仅出示一张写着'支持 Webhook'的演示 PPT。

在承诺本地 DID 前澄清 JIT 号码购买流程

详细询问号码是如何被搜索、锁定、购买并从预付费余额中扣款分配的。JIT(即时)意味着不存在假装成实际库存的静态货架；财务与运维团队共享同一个订单轨迹。如果条款清单承诺'目录中随时有号'却无法提供完整的锁定-购买-分配路径，运维团队最终将不得不被迫维护第二套账本。

要求明确在第一个 UTC 计费周期内由谁支付初始配置费和月租费，确保财务团队在号码分配后不会受到意外账单的困扰。

质询 Live 标识与 Setup 初始图块的区别

查明哪些产品只有在 Vault 呈现绿色就绪状态后才能显示 Live 标识，以及对买家而言'配置中'(in setup)究竟代表什么。如果一个频道尚未完成冒烟测试却贴上了 Live 标签，这属于严重的诚信缺失。运维团队应与销售人员一同逐项审核目录，标记所有超越实际就绪状态的虚假标识。

即将推出(Coming-next)的功能属于产品路线图的讨论范围，绝对不能混入第一周约束性的上线清单之中。

确认 STOP 退订与生产合规闸门

询问系统如何响应 STOP 关键字、黑名单抑制库存储在何处，以及针对您要使用的特定通道，哪些生产合规闸门会保持强制开启。在没有明确 STOP 责任人的情况下签署协议，会将首次用户投诉直接演变成严重的法律与送达率事故。

将 STOP 处理逻辑的解答与首日准备清单绑定，切勿为了追求上线速度而牺牲隐蔽但关键的合规控制。

从 IOSOR 开始

打开控制台的Webhook设置，核实心跳超时的监控责任人，并了解陈旧网关如何触发系统升级。在测试项目中演练按需号码的搜索、保留与分配流程，同时确认停止消息抑制表能切实阻断违规通道。

IOSOR 要点

买方检查清单必须在签署合同前强制落实运营透明度。要求本地号码具备清晰的保留-购买-分配流程、明确的Webhook心跳归属权，并经验证的上线徽章就绪状态，方能在流量涌入时防止灾难性的发布失败。

务必通过技术评估走查每个目录功能，确保设置磁贴与实际执行能力相符。切勿接受表面化的商业承诺，也绝不要在未经完整审计测试的停止抑制与生产合规网关上线前启动路由。

这篇指南有帮助吗？