工单系统接入号码状态查询：查询该放在哪一步
工单系统接入号码状态查询，真正难的是查询时机：工单创建时查、坐席点开时查还是夜里预取。这篇按场景讲清三个触点的代价、工单表里存原始状态还是存结论、结论放旧了怎么处理，以及上线前要跟业务对齐的字段口径。
🎁 免费试用手机号码状态查询 API
直连三网运营商 · 准确率 ≥99.9% · 支持携号转网识别 · 按次计费即买即用
客服团队提了个需求：坐席在工单系统里点开客户资料时，手机号旁边最好带一个状态标记，碰到空号就不用浪费一轮外呼。需求评审上没人反对，开发排了两周，上线了。
两周后，账单和投诉同时到。账单这边，一天几万工单，坐席随手点开看一眼就触发一次查询，「看两眼」占掉了大半调用量；投诉那边更麻烦，同一个客户，上午显示正常在网，下午再点开变成空号，坐席不知道该信哪个。
代码没写错，接口也没出问题。麻烦出在两个决定上：查询被放在流程的哪一步，以及结果在工单表里怎么存。
接口返回的是八种状态：正常在网、空号、通话中、不在网、关机、欠费、无短信能力、长时间关机。坐席屏幕上的注意力只有几秒钟，他要的不是这份清单，而是一句话：现在能不能打，短信能不能发。八种状态各自该对应什么动作，号码状态检测结果怎么解读：八种状态对应动作里整理过一版，本文只关心这些动作出现在工单里的方式。
这个翻译动作必须发生在服务端。让界面直接显示接口原话，等于把状态字典的解释责任推给最没有上下文的人。
映射规则写在配置里，和状态字典同版本发布。业务改口径时不用等开发排期，坐席端看到的文案也不会和后台判断打架。
「点开就带出来」这句话，落地时有三个位置可选。
最省事的是工单创建时查一次。调用量跟着工单量走，账好算，结果也能落库做统计。代价是时间差：工单创建完可能压在队列里几个小时才被坐席接手，那时结论已经旧了。
坐席点开时现查的实时性最好，代价是量跟着人的动作走：同一个人刷两遍页面就查两次，来回切标签也会算进去。一天几万工单的系统里，这条路很容易把量顶到工单量的两三倍，而多出来的那部分没有任何新信息。
夜里批量预取是成本最可控的一种：把第二天要处理的名单整批跑一遍，白天只读快照，坐席端零调用。代价是响应慢——上午新进的工单要等下一轮预取才有状态。
更常见的做法是两种叠着用：夜里预取打底，坐席端留一个按需刷新的入口，但刷新要节流——一张工单在一个时间窗内最多查一次，窗口内的结果直接复用。这层节流不做，等于把最贵的那条路径当成默认路径。想省量还有一层更便宜的思路，手机号状态查询免费能挡多少：粗筛与精查怎么分工里把粗筛与精查的分工拆得比较细。
存结论最省事：工单表多一列「可触达 / 不可触达」，界面拿来就能用。但结论是派生值，映射规则一改，历史工单里的结论就没法重算。
更稳的是存原始状态加查询时间，界面渲染时再映射一次。字段是这么几个：接口返回的原始状态、查询时间、结果的来源（预取还是按需刷新）、以及一个是否在覆盖范围内的标记。改了展示规则只影响渲染，不动历史数据；要回头看某条工单当时为什么被标成不可触达，原始状态和时间戳都在。
工单从创建到被处理，跨半天是常态，而关机、通话中这类状态几小时内就会变。这就是开头那个「上下午不一致」的来源——不是接口反复无常，是两次查询本来就在不同时点。
处理方式按后果分两档。会影响一次外呼动作的工单，进坐席视野之前自动重查一遍，用新结论覆盖展示值，旧值留在流水里；只是给坐席做个参考的工单，不重查，界面上把查询时间显式打出来。
显式展示时间值得单独强调：坐席看到「两小时前查询」和「刚刚查询」，对同一个状态的信任程度完全不同。
「无短信能力」这个词在开发眼里很清楚，在坐席眼里经常被理解成号码有问题。按用途重写一遍文案更实用，比如「电话可接通，短信不可达」，坐席照着选动作就行。
文案和映射规则共用一份配置，改一处两边都变。分开维护，三个月后必然出现界面提示和后台判断互相矛盾，而这类矛盾不会触发任何告警。
需求评审时把这几条写进文档，能省掉后面大半的返工：状态多久算过期、谁有权看完整号码、覆盖范围外的号码在界面上显示成什么、工单关闭后这些结果留不留、留多久。口径定了之后，放量的切法可以照号码状态查询接口上线：灰度、开关与回滚里按业务线分步走的做法。
边界这一条尤其要说清：名单里还会掺进几类接口给不出状态的号码——号段归虚拟运营商所有、卡是物联网卡、号码在境外，坐席端把它们显示成「未覆盖」，别跟查询失败混成同一个提示，否则每天都会有人跑来问「是不是接口坏了」。
另外两条容易漏的：号码状态只用于内部判断能不能触达，不作为对外出具的凭据；工单里保留完整号码的权限要和坐席岗分离，导出动作单独走审批。
想先验证触点选得对不对，可以从【手机号在网状态 API】按次计费起步：直连三网，返回的八种状态正好对应坐席端那几种动作分支，鉴权走请求头携带 AppCode，先跑一批真实工单的名单，看量落在哪个数量级，再定预取还是按需刷新。
文章评论
发表评论
请先注册/登录后评论