工作总结

时间:2026-04-22 作者:每天帮

话务员工作总结及工作计划。

今年是我从单纯接电话转向“接电话+看网管+跟现场”的第三年。说白了，就是左边耳麦接投诉，右边屏幕开工单，桌上还摊着本画满故障树的工作日志。

先放几组我盯了一年的数字：个人话务受理总量4200单出头，其中故障申报占68%，咨询类27%，投诉类5%。工单一次解决率91.3%，比去年涨了4.2个百分点；客户满意度4.82分（满分5），平均通话时长210秒。这些数字背后，是一个个凌晨两点的告警声和用户那句“终于好了”的叹气。

一个让我把话务员和运维角色真正焊在一起的夜晚

今年四月的一个夜班，凌晨两点十七分。一位客户打进来，声音压着火：“我这是第四遍报修了！你们每次都让重启，重启完撑十几分钟又断。”我调出历史工单——前三通电话，三个同事分别处理，话术惊人一致：“后台已刷新端口，建议断电重启光猫”“检测到信号正常，请观察使用”。典型的流程走完，问题还在。

我没急着说“您再试试”。让客户保持在线，我登录OLT网管系统，查他这个PON口下的光功率。收光在-27dBm附近来回跳，每15分钟左右掉线一次。这不是重启能解决的。我又调出同一分光器下另外五个用户的历史数据，发现最近三天都有不同程度的丢包和重传。判断是弱电井里的分光器尾纤接头氧化，或者受潮。

我直接联系了片区线维老张——我们有个不成文的约定：凌晨紧急故障，话务员可以绕过调度找他。我说：“XX小区3号楼弱电井，1:8分光器，光功率临界，建议直接换尾纤接头，测插损。”老张天亮后过去，拆开接头一看，铜绿都长出来了。换完，光功率从-28.3dBm跳到-18.7dBm。客户后来打来电话，不是投诉，是感谢：“你们终于有人懂技术了。”

那天我补了一条工单备注，现在成了班组内部的铁律：间歇性掉线，必须先查同一PON口下其他用户的掉线历史。这个动作加进去后，同类故障的重复报修率降了六成。

几个从工单里磨出来的“土办法”

我整理了一张故障模式速查表，贴在工位隔板上。比如“频繁掉线但重启能好一会儿”——90%是光衰在临界值附近波动，别让用户反复重启，直接查收光功率。“每晚8-10点准时卡”——优先看上联带宽利用率，八成是视频流量把端口堵了。“错误码691”——除了账密问题，还要查上次下线记录有没有正常释放，不然改了密码也没用。这张表现在全班组都在用，同类故障平均通话时长从280秒压到了190秒。

另一个我比较得意的事，是反哺知识库。运维部发的《故障处理手册》里，很多条目写着“检查链路状态”“确认设备正常”，但话务员根本不知道“检查”具体要敲什么命令、阈值是多少。今年我提交了12条修订建议，比如在“光猫LOS灯闪红灯”下面，我写的不是“建议重启”，而是“登录网管查该PON口收光功率，若低于-26dBm，直接派单给线维更换尾纤，无需用户重启测试”。目前有8条被采纳进新版手册。上个月新来的小刘跟我说：“姐，你写的那个‘低于-26直接派’太好用了，省了我跟用户解释半天。”

跨部门协作上，我和城域网的老周搞了个小闭环。当单日内同一网段出现3起以上拨号失败投诉，我直接拉群丢给他IP段和时间戳，他反向查BRAS配置或地址池状态。今年靠这个办法，提前发现了两次地址池耗尽和一次DHCP中继配置错误，避免了至少两百个用户反复拨号。

两件让我脸红的事

第一件是IPTV。新业务上线头两个月，用户打电话说黑屏，我只会照本宣科：“请重启光猫和机顶盒”“恢复出厂设置试试”。结果有次被运维老赵怼了：“组播VLAN都没配，你让用户重启到明年也白搭。”我一听火也上来了——你们上线新业务，培训材料就两页PPT，谁看得懂？但冷静下来一想，确实是自己懒了。后来我厚着脸皮跟了三个现场工单，蹲在用户电视机前看老赵配VLAN、测组播流，才彻底搞明白黑屏的根因。现在IPTV相关投诉，我能在90秒内判断是VLAN未下发还是节目源问题。 mTb31.Com

●每天帮必读干货:

话务员工作总结 | 电信话务员工作计划 | 话务员的工作计划 | 联通话务员工作总结 | 话务员工作计划 | 话务员工作计划

第二件是高峰时段压通时的毛病。晚上8-10点话务量大的时候，我有时会为了快点挂电话，给出“已为您刷新端口，五分钟后重启试试”这种过渡性方案。用户当时接受了，但问题没根治，第二天又打过来。后来我给自己定了个规矩：凡是给出“过渡方案”的工单，必须设置次日回访提醒。这么干了两个月，发现这类工单的重复来电率从15%降到了5%。说白了，多花一分钟做根因判断，比第二天再花五分钟擦屁股强。

明年我想干的三件事

第一，跟够10个现场工单。不是去晃一圈就走，而是要跟着线维从弱电井走到用户家，把分光器、尾纤、光猫、网线每个环节的实测数据记下来，回来写成“话务员能听懂”的故障特征表。

第二，建自己的案例库。每次处理完疑难工单，用固定格式记录：现象、网管查询步骤、判断依据、最终处理结果、踩过的坑。每月复盘一次，找出那些还没标准化的判别路径，写成小贴士分享给班组。

第三，主动回访重复报修用户。连续三次以上申报同一问题的，不再简单派单，而是由我先调出历史工单和网管数据，带着分析结论转给后端。目标是把这类用户的平均解决周期从三天压到一天。

话务员这活儿，说到底就是在90秒内从用户的牢骚里捞出关键信息，用网管数据验证猜测，然后给后端指一条准路。不讲漂亮话，数据闭环，故障清零。明年继续盯着那几个坑，一个个填。

推荐阅读: