转发"收不到码"之前，先填成一张故障票

你把那条消息截了图，转发到内部群，@了负责那个区域的销售。

五分钟后他回了一句：“具体什么情况？”

你又打开那张截屏看了一眼，发现你能说的和截屏上一模一样，一个字都没多：

“—可以帮忙看看吗？印尼用户 Indosat，晚上七点之后大面积收不到 OTP，error 112，已经三天了。——（示意性复合场景，非单一条原始消息）”

你把这句话念了一遍。销售追问：“是固定时段还是全天都这样？错误码对应什么原因？就一个人报还是多渠道都有？”

你答不上来。

这不是你经验不够。是这条消息本身的信息量，确实不够回答这三个问题。OTP（一次性验证码——注册、登录、转账确认时手机收到的那六位数字）的到达率抱怨，在群聊里长什么样都差不多：笼统的一句”收不到”。但值不值得当成一次替换窗口跟进，取决于你能不能把这句话拆开，填成一张有具体栏位的”故障票”。

下面就是这张票的四个栏位。

第一栏：国家 + 运营商——“印尼 Indosat”已经排除了什么

消息给了两个锚点：国家是印尼，运营商是 Indosat。

这两个词排除了第一种干扰：这不是跨境漫游用户在陌生网络下的偶发问题，而是本地用户在自己网络上看不到验证码。方向明确了。

但”Indosat”在这里指用户当前注册的网络，还是消息路由经过的中继节点？前者指向印尼本地的接收网关，后者涉及发送方与国际路由侧之间的合约路由。两条排查路径在第一步就分岔了。

仍需要人工核实的事：

• 这条抱怨背后是一个客户的上游用户在报，还是多个客户同时遇到？单个客户的反馈需要结合其日常发送量和送达率基线来判断——没有基线数据，“大面积”只是一个主观形容词。
• 同一时段有没有其他群或渠道也提到 Indosat？如果有，问题更可能在运营商侧的网关上，与具体发送方无关。

第二栏：时段——“晚高峰”需要一个时间范围对照

“晚上七点之后”——如果这个时间状语经过原始时间戳确认后仍然成立，它已经把排查方向从”系统故障”压窄到”对负载敏感的场景”。

印尼东七区的 18:00–22:00 是国际路由带宽最拥挤的窗口之一。一种典型的模式是：白天送达率正常，傍晚开始掉，深夜回升。如果数据验证了这一模式，指向限速或网关过载的概率远高于配置错误。

反过来，如果问题是全天均匀出现的——上午十点和晚上十点的失败率几乎一样——那就更可能是合约配置、账号白名单或内容模板层面的问题，与时段无关。

仍需要人工核实的事：

• “晚上七点之后”指的是印尼时间还是消息报告者所在时区？这个必须回到原始 Telegram 群的发送时间戳确认，截屏里看不到。
• 这三天是不是每一晚都在同一时段出现？偶发一晚可能是上游割接，连续三个晚高峰稳定复现才有信号价值。

第三栏：失败码——同一个 error，故障路径可能完全不同

“error 112”（示意值，非真实 SMPP 协议编号）。

在 OTP 发送场景下，失败码通常来自 SMPP 协议（Short Message Peer-to-Peer，短信点对点协议，验证码走的主要就是这个）。同样的”收不到”，不同失败码对应的物理原因相差很大：

• 如果失败码的含义是”目的网络不可达”，路由链路或对端网关有问题。
• 如果含义是”消息被拒”，发送方的账号配置或消息内容可能被目标网络拦截。
• 如果含义是”有效期过期”，说明消息在路由里滞留太久，抵达时已经过了运营商允许的存活时限。

而且，同一个运营商在不同时段可能返回不同的失败码——晚高峰返回”不可达”，白天返回”已送达”。这组对比本身的信号，比单独一个错误码强得多。

仍需要人工核实的事：

• 这个 error code 在你所关注的发送方内部文档里对应什么含义？不同服务商对 SMPP 失败码的分类和映射可能不同，不能靠通用解读替代。
• 三天内的失败码是否一致？如果每天都在变，说明问题可能在运营商上游动态切换，而不是固定在单一环节。

第四栏：持续时间——“三天”和”三个完整晚高峰”不是一回事

“持续三天”这个时长跨过了”偶发波动”的区间。一天可能由临时割接或光缆故障引起，三天且每晚重复，指向结构性路由问题的概率更大。

但”三天”需要拆成两个问题来看：

1. 是从第一天开始就每晚出现，还是前两晚正常、第三晚突然恶化？
2. 指的是三个完整的晚高峰周期，还是从某天晚上开始算到今天第三天？

前者形成了稳定模式，后者可能还在演变中——需要看今晚的数据才能判断趋势。

仍需要人工核实的事：

• 需要从发送方那里拿到这三天每小时的分时段送达率曲线。只有曲线能区分”固定时段限流”和”持续恶化中的故障”。
• 如果问题在第三天上午已经被对方修复，那这个替换窗口的时间戳已经过期了。

四个栏位凑齐之后

现在这张票不再是”印尼有人收不到码”，而是：

印尼 | Indosat | 东七区 18:00–22:00 | SMPP error（目的网络不可达）| 连续三个晚高峰 | 白天正常

六个条件放在一起，才构成一个值得核实的替换信号。但信号只是信号，凑齐之后第一件事不是联系客户，而是三样核实：

1. 回到原始 Telegram 群看完整讨论流。 你截屏的时候可能只看到问题，看不到后面有没有人回复”已调整路由”或”确认是运营商侧割接”。如果复核记录保留了上下文和后续回复，就直接从那里还原讨论——截屏只取了那个瞬间，而判断需要看到这条线索的完整演变。

2. 确认问题归属。 集中在一个运营商晚高峰时段的失败，需要先弄清楚发送方在 Indosat 方向上用的是哪条路由、那条路由在对应时段有没有已知的维护窗口再联系对方。

3. 检查合同窗口。 这个客户与现有服务商的合约中有没有触发更换条件的条款，以及到期日是什么时候。不是每一次抱怨窗口都对应一个打开的合同窗口。

你截的那张图之外，还有一段对话可能改了答案

截屏只能保存一条消息，但 Telegram 群里那条消息发出之后可能已经有了进展。对方技术可能已经回复”正在排查”或者”已联系印尼侧”。也可能其他客户在同一个问题下跟帖说”我们也遇到了”，或者群管理员发了一条置顶说”已知问题，预计明早修复”。

这些信息不在你的截屏里。而它们直接影响一个判断：这个问题是持续打开的替换窗口，还是已经被对方堵上的历史记录。

所以这张故障票填完之后，最后一步不是转发给销售，而是回到原始群，把从那条消息发出到现在的所有回复读一遍。如果问题已经被标记为”已解决”，那张票就归档，不跟了。如果问题还挂在空中，并且合约窗口也对得上，到这一步再决定要不要联系客户。

至于怎么开口联系，那由你自己判断。这篇文章能帮到的事只有一件：下次你在群里又看到”收不到码”时，知道在转发之前，先把那张票的四个栏位填齐。

产品范围

市场与风险讨论属于辅助证据

Top商业线索的主任务是 Telegram 获客。市场与风险讨论可以为候选线索补充上下文，但不会自动成为已核实事故、趋势或销售机会。

查看产品工作流与边界 →