微信支付成功率从86%到95%：无线网优QC实践全解析

简介：QC小组《提升微信支付成功率》活动成果报告，面向通信行业网络优化工程师、QC小组成员及关注移动支付体验的运营管理人员，完整呈现了从课题选择、目标设定、可行性分析、原因分析、要因确认到对策实施与效果检查的全流程。报告针对设备故障站点处理、不同用户数门限小区参数调整、3/4G合路更换2T2R天线、天线下倾角优化等关键措施均有细化方案，并附有要因确认计划表与对策实施计划，便于读者借鉴同类网络质量改进项目。资源共1个docx文件，压缩包整体约8.48MB，内容以目录化章节呈现，图文结合，结构清晰。目前已有617人学习浏览，适合需要撰写QC成果报告或开展网络优化专项提升的团队参考，可直接沿用其分析框架、表格模板及汇报逻辑。

1. 先别怪微信服务器：支付成功率是张网络成绩单

微信支付扫码后一直转圈，最后弹“支付失败”——这种投诉在2018年前后基本被当成腾讯服务器问题处理，直到网优团队把成功率按网格拉出来才发现，绝大多数失败其实发生在无线网络这一侧。我手上这份深圳联通网络创优QC小组（CU-GUANGD-SHENZ-2018-001）的活动成果报告，记录的就是这件事：11个工程师，从2018年2月到12月，耗时650小时，把微信支付成功率从86.08%一路提到95%以上的完整过程。它适合三类人：干无线网络优化的、在带QC小组的、以及任何想把“用户感知类指标”真正拆解落地的人。看完你会拿到一整套可复用的目标论证、要因确认和实施方法，而不是空泛的“加强优化”四个字。

2. 目标从哪来：86.08%到95%的三层论证

2.1 一个指标的三层含义：成功率、失败次数与业务感知

微信支付成功率在报告里定义得很直接：微信支付成功次数占微信支付总次数的比例。看着像业务指标，但对网优人来说它就是一张网络成绩单。一次扫码支付，从手机发出请求到微信服务器返回确认，中间走的是移动网络链路，弱覆盖会让请求发不出去，拥塞会让请求排队超时，干扰会让数据反复重传，任何一环出问题，用户看到的就是“支付失败”。

所以报告里特意点出一个运营痛点：网络覆盖较差的区域，商户可以收，消费者却不能付，O2O闭环断在最后一步。这也是为什么微信支付成功率能作为网络优化课题——它比单纯的覆盖率、掉线率更贴近用户真实体验，而且可统计、可量化、可按网格拆解，天然适合作为QC活动的攻关对象。小组把统计口径定在2017年下半年的微信支付数据上，发现支付总量上升明显，但成功率波动较小，稳定在86.08%，这个值就成了后续所有分析的基线。

2.2 目标从哪来：内部分布、外部对标与省公司指令

目标95%不是小组自己拍脑袋定的，有三层依据。最上层是省公司下发的《关于进一步提升腾讯系应用网络感知的通知》，明确要求2018年底前各地市微信支付成功率不得低于95%。中间层是内部分析：小组把深圳293个网格2018年4月的成功率全部拉出来，发现有17个网格已经大于95%，说明这个目标在现有网络基础上是可达的，不是空喊。

提示：网格分布比平均值重要得多。全市平均86.08%背后，是13个网格低于80%、26个网格在80%~85%之间、83个网格在85%~90%之间。改善空间不在平均值里，在那些低于85%的网格里。

外层是对标分析。小组挑了业务量相当的几个地市做对比，重点参考同样用中兴设备的A市——业务量与深圳相当，成功率95.36%，比深圳高9.28个百分点。同设备厂家的地市能到95%，说明网络制式、设备能力不是瓶颈，优化方法才是。这张对比表的价值在于：它提醒你，对标对象必须先统一设备厂家，华为设备和爱立信设备的参数体系、优化手段都不一样，混在一起对标结论基本没有参考意义。

2.3 可行性计算：一个能直接套用的公式

三层论证还不够，报告里给了一个可以套用的目标可行性公式，这是整份报告计算上最扎实的部分。公式是：目标值 = 原始成功率 + 失败次数占比 ×（原因一占比 × 解决比例 + 原因二占比 × 解决比例）。代入数据：86.08% +（1 - 86.08%）×（52.10% × 80% + 30.21% × 80%）= 95.25%。

这个式子的逻辑是：只有失败次数里有改善空间，所以用（1 - 原始值）做基数；两个症结一共能解决多少，取决于各自的占比和解决比例。80%的解决比例来自小组以往的优化经验，不是乐观估计，是同类问题在历史项目里的平均解决能力。算出来95.25%大于95%，目标才正式立项。我拆这份报告时最大的感受是：这一步是很多QC小组偷懒的地方，要么不量化，要么直接把目标写成“大幅提升”，而这个公式可以直接抄去用在其他业务指标上。

3. 拆解要因：排列图、树图与量化确认

3.1 症结分析：用排列图定位两个“大头”

报告把影响微信支付的因素先做了一次清洗，排除了物业问题、小区供电、天面环境这些与无线网络关联小且难以改变的项，留下六类可干预因素，然后按每天的支付失败次数做排列图。这张排列图是典型的帕累托分析：无线质量每天导致436741次失败，占52.10%；设备稳定性每天253243次，占30.21%；两者累计82.31%。

这两项被认定为症结的依据很朴素：加起来超过80%，集中火力解决它们，投入产出比最高。后面所有末端原因树图都从这两个症结往下长，而不是从六类因素平均用力。这一步的关键是分类字段要干净，如果原始数据里失败原因缺失率高，排列图会失真，后面全白做。

3.2 末端原因树图：从症结往下挖出七条线索

小组用头脑风暴收集了所有可能原因，筛掉不可抗因素后，整理出七条末端原因：信道功率设置不合理、室内天线功率分配不合理、用户数门限设置不合理、天线角度调整不合理、天线选型不合理、天线端口连接错误、基站设备故障频发。前六条挂在“无线质量”症结下，最后一条直接对应“设备稳定性”。

这七条拆得很讲究，每一条都有明确的排查对象和可能的动作落点。信道功率和室分功率分配属于后台参数类，改了就能验证；用户数门限与拥塞直接相关，支付请求排队超时大概率挂在这；天线角度、选型和端口连接属于工程工艺类，涉及现场作业；基站设备故障频发则是维护侧的主导因素。七条原因相互独立、没有交叉，这一点对后续要因确认很重要——如果两条原因指向同一类动作，确认过程会互相干扰，最后分不清是哪个动作起的效果。

3.3 要因确认计划表：把“合理”改成可验收的数字

末端原因只是假设，要认定“要因”必须逐条用数据确认。报告里的要因确认计划表是全篇我最欣赏的部分：每条末端原因都配了确认内容、确认方法、确认标准和完成日期，标准全部量化。信道功率设置合理的比例要大于90%；室分天线功率分配差距绝对值大于2.5dB的比例要小于1%；用户数门限值在40~80之间的比例大于95%；天线下倾角不合理比例低于10%；2T2R天线占比大于80%；天线端口连接错误比例小于8%；基站设备周故障率小于0.6%。

这些阈值的来源是历史经验和设备规格：2.5dB的功率差会导致覆盖明显不均，40~80的用户数门限覆盖了95%的小区实际负荷。我复现这份计划表时最大的体会是：确认标准不量化，要因确认就会变成开会扯皮，你说合理我说正常，最后谁都说服不了谁。确认结果必须是任何人拿着同一份数据都能复算出相同结论的数字。

4. 要因确认避坑指南：口径、阈值与数据陷阱

4.1 数据口径不一致，前后对比直接翻车

现象：活动初期提取的成功率与省公司通报的对不上，同一指标差两三个百分点，无法判断优化是否有效。

原因：统计周期不统一，有的按天、有的按周；分子分母定义也有差异，有的除支付总次数，有的除支付请求次数。口径没锁死，对比就没有意义。

解决：统一按天粒度、按网络侧统计口径重新拉数，并固定统计版本号，之后所有对比都用同一套口径。谁要改口径，必须同步刷新历史数据，不能新旧口径混着比。

4.2 排列图分类太粗，症结判断失真

现象：第一次排列图把“无线质量”作为一个大类，占比52.10%，但不知道里面是弱覆盖还是干扰还是拥塞，后续没法定动作。

原因：分类字段取自现网统计，粒度不够细，失败原因没有细分标签，大类把多个独立问题混在一起。

解决：先按失败信令的原因值拆细，区分弱覆盖、上行干扰、接入拥塞，再做排列图，保证每一个症结都能对应到可执行的动作。如果分类粗到连动作都映射不了，排列图做得再漂亮也是摆设。

4.3 确认标准没量化，要因确认变成开会扯皮

现象：要因确认计划表初稿里写“信道功率设置合理”“天线角度正常”，现场验证的人凭感觉填结论，你说是合理的，我说是不合理的。

原因：标准没有数字化，验收无依据，确认结果无法复核。

解决：把每一条标准改成数值阈值并指定确认方法，比如“合理比例大于90%”“错误比例小于8%”。有了阈值，确认结果谁都能复核，不需要权威拍板，数据自己会说话。

4.4 只看平均值，把重灾区平均掉了

现象：全市成功率86.08%，看起来离95%不远，团队差点直接按“整体优化”铺开干。

原因：平均值掩盖了网格差异，13个低于80%的网格被高分网格平均掉了，从全市均值曲线看，问题似乎不紧迫。

解决：先看网格分布图，把低于85%的网格单独标记，优先处理低值区，平均值只作为总进度参考。优化资源永远先投给拖后腿的重灾区，而不是投给已经达标的舒适区。

4.5 故障统计窗口太短，稳定性被高估

现象：某周故障率0.4%，低于0.6%的标准，判定设备稳定，结果下个月连续出现基带板故障，支付成功率又掉下去。

原因：单周窗口太短，恰好避开故障高发期，设备稳定性判断被偶然性左右。

解决：窗口拉长到一个月，且统计单位从“故障次数”改成“故障影响范围”，按涉及用户数和支付失败次数加权，更贴近真实影响。一个影响一万用户的故障，比影响一百用户的故障权重高得多，这样评估设备稳定性才靠谱。

5. 四步对策落地：故障、门限、天线与倾角

5.1 故障站点处理：先算影响面，再动手

对策一针对“基站设备故障频发”，处理原则不是按故障时间排序，而是按影响面排序。我会先拉故障工单，统计每个故障站点覆盖范围内的微信支付失败次数和涉及用户数，再结合网格成功率打分，得分高的优先处理。处理动作一般是更换故障板卡、重启基带单元或升级固件，操作完成后等一个话务高峰周期，观察目标站点支付成功率是否回到正常水平。

这个逻辑值得强调：一个在偏僻站点挂了三天的小故障，影响可能不如商圈站点挂半小时。如果不按影响面排序，会把人力耗在低产出站点上，活动节奏被拖垮。报告里这个对策选得准，因为设备稳定性本来就是第二症结，处理完故障站点，周故障率压到0.6%以下，这个症结就算闭环了。

5.2 用户数门限分档：不搞一刀切

对策二针对“用户数门限设置不合理”，问题出在原来所有小区用同一个门限值。高话务小区用户数一上去就触发拥塞，支付请求排队超时；低话务小区门限设太低又浪费资源。我一般会先把小区按日均用户数分三档，再配门限：低于200户的小区门限设80，200到500户设60，高于500户的商圈、交通枢纽设40。

门限调整有个讲究，不能一天把所有小区全改了。RRC连接成功率对门限很敏感，我一般分批改，每批覆盖总小区数的三分之一，改完观察一个完整话务日，确认成功率没掉再改下一批。报告里要求调整后门限值在40~80区间的小区比例大于95%，这个定量目标就是用来卡这个动作的完成度的。

5.3 3/4G合路站更换2T2R天线：为什么是2T2R

对策三针对“天线选型不合理”，具体动作是3/4G合路站把旧天线换成2T2R天线。2T2R是两发两收，相比单发单收多了接收分集增益，对上行覆盖改善明显。微信支付是典型的上下行业务，手机发起的支付请求走上行，上行弱覆盖直接导致请求发不出去，2T2R的上行增益正好打在痛点上。

这个对策的适用边界要讲清楚：它适用于3/4G合路、天线老化或故障更换的场景，解决的是覆盖能力问题；如果站点已经用了4T4R天线且容量受限，换回2T2R反而是倒退。更换流程一般是天线选型确认、现场更换、驻波比测试、功率校准，最后做一次业务验证。活动要求2T2R天线占比大于80%，这个指标卡的是全网换天线的完成面，不是单站验证。

5.4 天线下倾角调整：按业务需求校准覆盖

对策四针对“天线角度调整不合理”，核心是按实际业务分布调整天线下倾角。下倾角由机械下倾和电下倾组成，调大下倾角能压近端覆盖、减少越区干扰，但调过头会让主覆盖方向出现空洞。常规做法是先核查全网工参，找出明显不合理的小区，再用路测确认越区覆盖和覆盖空洞位置，最后按业务热点分布调整。

调整时有个经验值：市区高楼场景下倾角一般调大，用垂直覆盖换深度覆盖；郊区或城中村平层场景下倾角要收着调，避免把信号压到楼顶以下。每次调整幅度控制在1到2度，调完复测目标道路和室内的参考信号接收功率。报告中“下倾角不合理比例低于10%”的确认标准在这里就变成了验收线，所有调过的站点都要能证明“不合理比例”被压下来了。

6. 效果验证与迁移：把这次的方法带到下一个指标

6.1 效果验证：复测网格，别只看全市均值

对策全部落地后，验证不能只看全市平均值，要把293个网格重新拉一遍成功率，对照目标线95%，看还有多少个网格在目标线以下。报告在效果检查阶段同时做了效益评估：支付成功率提升，商户和用户双端体验改善，腾讯侧合作满意度上升，这些都是可以折算的隐性收益。任何优化活动，不把效果验证做细，前面的努力都说不清价值。

6.2 巩固措施：把临时调整固化成基线参数

巩固措施里最值得借鉴的是“参数基线库”的思路：把这次调整后的用户数门限、下倾角、天线选型结果固化成参数基线，后续新开站、新入网设备直接按这个基线配置，避免回到旧参数。配合周粒度成功率报表和故障巡检机制，一旦指标回落能第一时间触发排查。这套东西不是QC活动结束就扔的，而是转成日常运维动作。

6.3 方法论迁移：从支付成功率到其他业务指标

这套PDCA流程完全可以搬到别的业务感知指标上：视频播放成功率、网页首包时延、游戏时延都可以按同一套路做。路径很清晰：选课题定目标、网格分布做内部分析、同设备厂家对标做外部分析、排列图定症结、末端原因树图列假设、量化标准确认要因、按要因定对策、复测验证。这套流程最大的价值是每一步都有数据支撑，每一步的结论都能复核。

那段时间我们踩过一个坑：跳过要因确认直接凭经验定对策，结果实施两周后效果不明显，回头补数据才发现漏了一条要因。从那以后，我每次做要因确认都强制先把确认标准写成数值阈值再开工，不够量化的原因一律不许进对策阶段，这个习惯帮我避开了后面好几个项目的返工。希望帮到你。

本文还有配套的精品资源，点击获取